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ABSTRACT 


The  focus  of  this  research  is  on  extracting  data  from  the  volatile  random 
access  memory  (RAM)  on  a  personal  computer  running  Microsoft’s  Windows 
Vista  operating  system,  while  minimally  affecting  the  existing  data.  The  projected 
work  includes  the  development  of  a  kernel-mode  device  driver  with  the 
capabilities  on  one  or  more  versions  of  Microsoft  Windows  Vista,  a  user-mode 
application  that  interacts  with  the  driver,  usage  documentation  and  outcome  of 
the  research. 

The  main  objectives  of  the  research  is  to  show  the  possibility  of  extracting 
information  from  the  random  access  memory  using  a  user  mode  application  (with 
a  suitable  driver  already  installed)  and  to  document  the  process  of  Window  Vista 
driver  development,  so  that  future  works  in  this  area  can  benefit  by  putting  more 
effort  into  specific  research  rather  than  configuring  a  development  environment. 
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I.  INTRODUCTION 


A.  BACKGROUND  AND  MOTIVATION 

1.  Primary  Memory  (Random  Access  Memory) 

The  Primary  Memory  or  Random  Access  Memory  (RAM)  also  referred  to 
as  main  or  real  memory  is  typically  considered  to  be  a  volatile  resource.  The 
data  residing  on  the  memory  becomes  less  reliable  as  power  is  weaned  from  it. 
Data  stored  in  RAM  persists  briefly  if  power  is  not  refreshed  [1],  Some  factors 
that  affect  the  persistence  of  data  in  memory  [2]  include: 

•  System  Activity 

•  Main  memory  size 

•  Data  Type  and 

•  Operating  System 

Both  user  space  applications  and  the  operating  system  kernel1  use  this 
form  of  storage  to  store  data  and  execution  codes.  Since  all  executions  leave  a 
trace  on  the  primary  memory,  there  is  an  abundance  of  in-memory  data  at  any 
time.  Inspecting  a  snapshot  of  memory  can  reveal  or  help  reconstruct  the  state  of 
a  system  when  the  memory  snapshot2  was  taken.  This  includes  not  only  current 
running  processes  but  also  terminated  processes  as  the  portions  of  memory 
used  by  them  (the  terminated  processes)  will  not  be  purged  when  these  portions 
are  no  longer  required  for  current  operation  [3], 


1  User  space  is  often  referred  to  as  “ring  3”  or  “privilege  level  3.”  Similarly,  kernel  space  is 
often  referred  to  as  “ringO”  or  “privilege  level  0.”  Both  are  artifacts  of  Intel’s  architectural 
protection  mechanisms  present  in  the  CPU. 

2  For  purposes  of  this  paper,  a  “memory  snapshot”  is  simply  an  archive  of  the  state  of  RAM 
at  a  point  in  time,  saved  to  a  file  for  example. 
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2.  Analysis  of  Forensic  Data  from  Volatile  System  Memory 


It  is  therefore  beneficial  to  analyze  the  content  of  RAM  to  gain  insight  into 
either  the  well  being  of  the  system  or  to  gain  access  to  information  that  is  hidden 
or  not  available  in  plain  sight.  This  information  include  open  TCP/UDP  ports/raw 
sockets/active  connection,  memory  mapped  files  and  caches  such  as  web 
addresses  and  typed  commands.  Information  that  is  usually  obscured  or  not 
even  present  on  disk,  such  as  passwords,  can  potentially  be  retrieved  from  an 
analysis  of  RAM. 

Since  most  modern  operating  systems  do  not  purge  the  information  on 
RAM  until  the  space  is  needed,  information  related  to  recently  terminated 
processes  can  also  be  extracted.  This  presents  special  significance  for  forensics 
purposes.  The  applications  are  countless  and  can  range  from  trying  to  extract 
messages  from  an  Instant  Messenger  of  a  kidnapped  child  to  help  with  an 
investigation  in  trying  to  prove  that  someone  has  executed  certain  programs  that 
he  or  she  has  recently  terminated. 

The  applications,  however,  are  not  limited  to  just  aiding  criminal 
prosecution  and  investigations.  Computer  systems  in  large  corporations  and 
institutes  such  the  U.S.  Department  of  Defense  are  high  value  subversion 
targets.  The  sensitivity  and  value  of  the  information  on  these  systems  makes  it 
important  not  only  to  protect  these  systems  but  also  to  detect  the  presence  of 
malicious  software.  An  offline  analysis  of  a  memory  image  is  one  of  the  best 
ways  to  defeat  most  known  anti-forensic  technique  and  discovering  Rootkits  [2] 
[4]. 


3.  Tools  used  for  Volatile  Memory  Acquisition 

There  are  many  known  techniques  and  tools  available  for  capturing  a 
volatile  memory  image.  They  can  be  broadly  categorized  into  Hardware  and 
Software  based  techniques,  each  method  with  its  own  suitability  and  limitations. 
These  techniques  are  discussed  below: 
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a.  Hardware  Based  Techniques 

The  most  direct  method  would  be  to  have  a  piece  of  dedicated 
hardware  for  the  sole  purpose  of  creating  a  system  memory  dump,  perhaps  at 
the  push  of  a  button.  A  proposed  method  was  to  use  a  PCI  card  that  disables 
the  CPU  and  use  DMA  to  access  the  host  memory,  creating  the  memory  image 
on  a  connected  device  [5],  This  has  the  major  disadvantages  of  requiring  the 
device  to  be  installed  prior  to  an  incident  and  the  cost  associated  with  purchasing 
these  devices  for  all  computers  in  an  organization. 

Another  technique  makes  use  of  the  bus  mastering  capabilities  of 
the  Firewire  protocol  for  imaging  the  memory  of  arbitrary  host  [6],  This  is  a 
feature  of  the  Firewire  protocol.  Anyone  with  physical  access  to  a  machine  with 
a  working  Firewire  port  can  read  and  write  to  the  main  memory  of  the  system. 
This  technique  obviously  requires  the  target  system  to  have  a  firewire  port 
present.  Making  use  of  this  technique  would  require  that  the  target  system  be 
equipped  with  the  necessary  Firewire  hardware  and  software  (device  driver). 
More  importantly,  the  same  vulnerability  that  is  exploited  for  imaging  the  memory 
can  also  be  used  to  subvert  the  system.  This  is  therefore  not  a  good  way  for 
acquiring  volatile  memory. 

b.  Software  Based  Techniques 

A  common  UNIX  program  that  is  used  for  low  level  copying  and 
conversion  of  data  is  dd.  Specifying  the  /dev/mem  as  the  input  file  parameter,  dd 
can  be  used  to  image  the  data  in  the  RAM  of  UNIX  systems.  George  Garner 
successfully  ported  this  tool  to  Windows  system  in  2006  [7], 

Helix  is  a  bootable  CD  with  a  customized  distribution  of  Ubuntu 
Linux  [8],  It  is  a  computer  forensic  toolkit  used  for  incident  response.  It  is  also 
capable  of  creating  an  image  of  the  data  that  exists  in  RAM.  This  feature 
however  does  not  work  in  the  newer  versions  of  the  Windows  Operating  System 
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as  user  mode  applications  are  no  longer  capable  of  directly  accessing  RAM.  As 
such  this  is  not  a  viable  way  to  acquire  a  memory  image  of  system  running 
Windows  Vista. 

Some  implementations  of  Virtual  Machine  Concept  [9]  such  as 
VMWare  [10]  provide  a  means  of  taking  a  snapshot  of  the  state  of  a  machine. 
This  includes  the  CPU,  memory  (main  and  virtual),  hard  disks,  active  processes, 
etc.  When  a  snapshot  of  the  machines  is  taken,  the  contents  of  the  memory  is 
preserved  and  stored  as  a  file  on  the  host  machine3.  This  form  of  capturing  the 
image  content  of  memory  is  particularly  useful  for  research  and  analysis  of 
memory  images.  However,  this  method  does  not  address  the  issue  of  creating  a 
memory  image  on  a  live  (non-virtualized)  system. 

4.  Windows  Operating  System 

The  focus  of  this  research  is  on  extracting  data  from  the  volatile  random 
access  memory  (RAM)  on  a  personal  computer  running  Microsoft’s  Windows 
Vista  operating  system,  while  minimally  affecting  the  existing  data.  The  research 
work  includes  the  development  of  a  kernel-mode  device  driver  with  the 
capabilities  on  one  or  more  versions  of  Microsoft  Windows  Vista,  a  user-mode 
application  that  interacts  with  the  driver,  and  a  thesis  that  documents  the 
development  process  and  the  research  findings. 

The  device  driver  is  capable  of  exposing  the  volatile  memory  as  a  read 
only  media  (similar  to  a  CD-ROM).  The  MemReader  tool  will  also  include  a  user 
mode  application  that  makes  use  of  this  device  driver  and  writes  the  content  of 
the  memory  unto  a  specified  storage  media. 

The  thesis  also  documents  the  developmental  process  and  captures 
information  on  kernel  driver  development.  This  includes  some  problems 
encountered  and  certain  knowledge  and  gotchas  that  will  aid  future  students 
working  in  this  area  of  research. 


3  Often  RAM  is  preserved  as  a  single  file  with  a  .vmem  extension. 
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B.  RESEARCH  METHODOLOGIES  AND  ORGANIZATION 


1.  Primary  Research  Question 

•  Is  it  possible  to  build  a  driver  capable  of  extracting  data  from  the 
volatile  memory?  If  so,  in  what  ways  will  the  machine  state  prior  to 
acquisition  (volatile  and  non-volatile  memory)  be  affected  by  this 
method  of  acquisition? 

2.  Subsidiary  Research  Questions 

•  What  are  the  different  ways  the  device  driver  can  be  employed  (i.e. 
at  runtime,  boot  time)  to  extract  data  and  what  are  the  differences 
(between  these  ways)? 

•  How  portable  is  the  device  driver  between  different  Windows  Vista 
versions? 

•  How  does  the  tool  differ  from  the  plethora  of  tools  becoming 
available  in  the  market4  in  obtaining  an  image  of  volatile  RAM  and 
how  does  the  image  captured  by  our  tool  compare  with  those 
captured  by  the  others? 

3.  Assumptions 

Memory  management  is  often  carried  out  dynamically  by  the  operating 
system  to  cater  to  the  needs  of  existing  and  ongoing  services  and  processes. 
This  also  means  that  the  content  of  the  memory  is  constantly  changed;  hence, 
the  term  “volatile  memory”.  It  is  also  relatively  difficult  to  determine  the  exact 
content  and  location  of  data  residing  in  memory.  This  makes  verifying  the  output 
of  any  MemReader  a  difficult  job. 


4  ManTech’s  DD  was  not  available  when  work  on  this  thesis  was  started.  Below  we  provide  a 
comparison  of  our  work  with  “DD.” 
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The  content  of  RAM  can  also  be  captured  when  a  snapshot  of  a  system  is 
taken  by  VMware.  To  use  this  method  of  comparison  for  this  research,  the 
snapshot  would  need  to  be  taken  immediately  after  the  image  of  RAM  is  created 
by  an  imaging  tool.  The  instability  caused  to  systems  during  device  driver 
development  means  that  it  is  not  always  possible  for  the  tool  being  developed  to 
terminate  gracefully  before  it  crashes  the  system.  This  method  of  collecting  the 
RAM  images  for  comparison  was  therefore  not  chosen. 

For  the  purpose  of  this  research,  the  ManTech’s  DD  (MDD)  tool  was  used 
to  create  a  RAM  image  that  was  used  as  a  baseline  for  comparison  with  the  RAM 
image  created  by  the  MemReader  driver  and  application.  The  RAM  image 
create  by  MDD  is  assumed  to  be  correct  and  therefore  suitable  for  validation 
purposes. 

4.  Scope 

Windows  Vista  Business  was  the  version  of  the  Windows  operating 
system  used  for  both  the  development  and  testing  of  the  tool.  Although  the 
Window  Driver  Kit  (WDK)  [39]  provides  the  development  environment  for  some 
versions  and  architectures  (like  the  x86  and  x64).  This  project  was  only 
interested  in  the  development  of  a  tool  for  the  Intel  x86  architecture. 

Since  version  of  Windows  later  than  Windows  Vista  require  kernel  mode 
drivers  to  be  signed,  a  self-signed  certificate  created  using  the  MakeCert  tool  in 
WDK  can  be  used  for  self  signing  purposes. 

5.  Chapter  and  Appendix  Overview 

This  thesis  is  comprised  of  the  following  chapters  and  appendices: 

Chapter  I:  introduction  -  This  chapter  gives  an  overview  on  the  thesis. 
This  includes  some  background  information,  objectives  and  scope  of  the 
research  work  and  a  brief  overview  of  the  proceeding  chapters. 
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Chapter  II:  Background  of  Windows  Device  Drivers  -  This  chapter 
touches  on  the  background  of  Windows  Device  Drivers  that  will  be  beneficial  for 
understanding  the  rest  of  the  thesis.  The  information  is  also  a  good  starting  point 
for  anyone  that  is  interested  in  taking  up  Windows  device  driver  development. 

Chapter  III:  Requirements  and  High  Level  Design  -  The  chapter 
describes  the  requirements  for  developing  a  device  driver  for  Windows.  This 
includes  the  testing  the  debugging  requirement.  There  is  also  a  comparison 
between  the  available  tools  that  can  extract  a  RAM  image  on  a  Windows  system 
and  the  driver  that  was  developed. 

Chapter  IV:  Implementation  -  This  chapter  is  presents  the 
implementation  strategy  adopted  in  this  research  and  outlines  some  of  the 
problems  encountered. 

Chapter  V:  Test  Methodology  -  This  chapter  presents  the  methods 
adopted  in  this  thesis  to  verify  the  correctness  of  the  work. 

Chapter  VI:  Results  and  Analysis  -  This  chapter  presents  the  results  of 
the  testing.  This  includes  method  used  in  gathering  the  results  and  an  analysis 
of  the  collected  images. 

Chapter  VII:  Future  Work  -  This  chapter  proposes  areas  of  research 
work  that  can  be  further  extended  from  the  outcome  of  this  research. 

Chapter  VIII:  Conclusions  and  Recommendations  -  This  chapter 
summarizes  the  conclusion,  discusses  the  major  challenges  and  presents  certain 
recommendation  regarding  the  ramifications  of  this  research. 
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II.  BACKGROUND  OF  WINDOWS  DEVICE  DRIVERS 


A.  OVERVIEW  OF  THE  SIGNING  PROCESSES 

Digitally  signed  kernel-mode  software  is  a  process  that  attempts  to  ensure 
security  on  computer  systems.  Microsoft’s  Windows  Vista  relies  on  digital 
signatures  for  kernel-mode  code  to  increase  the  safety  and  stability  of  the 
Windows  platform.  All  64-bit  kernel-mode  software  intended  for  x64-based 
computers  running  Windows  Vista  must  be  digitally  signed.  This  applies  to  boot- 
start  drivers  for  x86  and  x64  versions  of  Windows.  Microsoft  however 
encourages  publishers  to  digitally  sign  all  software,  including  device  drivers  for 
both  32-bit  and  64-bit  platforms  [35], 

1 .  Kind /  Type  of  Signatures 
a.  Test-Signing 

This  refers  to  using  a  test  certificate  to  sign  a  pre-released  version 
of  software  for  use  on  test  computers.  There  is  a  MakeCert  [40]  utility  program 
included  in  the  Window  Driver  Kit  (WDK)  installation,  which  generates  a  self- 
signed  certificate  that  developers  can  use  to  sign  kernel  mode  binaries.  The  boot 
configuration  of  the  machine  must  be  changed,  using  the  bcdedit.exe  command 
[57],  before  test-signed  drivers  will  be  loaded. 

2.  Software  Publishing  Certificate  (SPC) 

A  Software  Publishing  Certificate  (SPC)  is  used  for  signing  the  catalog  file 
for  a  driver  package.  A  SPC  can  be  obtained  from  a  Commercial  Certificate 
Authority  (CA).  The  list  of  CAs  that  provides  SPC  that  can  be  used  for  kernel¬ 
mode  code  signing  is  available  at  the  Microsoft  Website  [41].  A  corresponding 
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cross  certificate  from  Microsoft  is  needed  together  with  the  root  CA  issued  by  the 
SPC,  so  that  the  signature  can  be  verified  by  a  trusted  root  authority  known  to 
the  Windows  Vista  operating  system. 

B.  MINIMAL  REQUIREMENTS  TO  GET  THE  DRIVER  LOADED 

A  driver  using  the  Kernel  Mode  Driver  Framework  (KMDF)  provided  by  the 
WDK  is  a  kernel  module  that  lives  permanently  inside  the  system.  In  many  ways, 
a  driver  is  treated  by  Windows  as  a  regular  service  that  can  be  started  and 
stopped  just  like  any  other  system  service.  The  two  steps  involved  in  installing  a 
driver  are: 

1 .  Registering  the  driver  as  a  system  service 

2.  Enabling/  Starting  the  driver/  service 

The  Service  Control  Manager  exposes  APIs  that  can  be  used  to  install 
and  start  a  device  driver/  service  from  any  Win32  application.  It  is  therefore 
possible  to  register  and  start  a  driver  programmatically. 

1.  Registering  Drivers  and  Services 

A  service  can  registered  in  one  of  the  two  ways: 

a.  CreateService  API 

The  CreateService  API  can  be  used  to  register  a  driver  as  a  system 
service.  Details  of  the  API  call  can  be  found  at  Microsoft  Developer  Network 
(MSDN)  documentation  [20],  The  service  StartType  [18]  can  be  specified,  as  a 
parameter  to  the  CreateService  API,  when  the  service  is  being  registered. 

b.  Manually  Editing  the  Windows  Registry 

The  CreateService  API  creates  the  relevant  entries  and  values  in 
the  Windows  registry.  It  is  possible  to  manually  create  these  values  in  the 
following  registry  by  adding  a  new  subkey  with  the  name  of  your  driver.  The 
registry  entry  will  look  like: 

HKEY  LOCAL  MACHINE\System\CurrentControlSet\Services\<dri ver  name> 
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The  registry  values  of  the  name,  path  and  start-type  of  the  driver 
need  to  be  supplied. 


Registry  Value 

Description 

Example 

DisplayName 

Name  of  service/  driver  as  it  appears  on  the 
service  list 

IP  Traffic  Filter  Driver 

ImagePath 

Full  path  to  the  driver  (or  just  the  filename  if  it 
resides  in  the  system32\drivers  directory) 

system32\DRIVERS\ipfltdrv.sys 

Start 

The  point  where  the  service  is  started 

3  (SERVICE_DEMAN D_START)5 

Type 

The  type  of  service 

1  (SERVICE_KERNEL_DRIVER)6 

Table  1.  Example  Service  Registry  Entry 


2.  Starting  the  Service 

After  the  driver  has  been  registered  as  a  system  service,  it  can  be  loaded 
(and  unloaded)  using  the  Service  Control  Manager.  It  can  be  started  either 
programmatically  using  the  StartService  API  or  using  the  Windows  net 
command: 

net  start  <service  name> 

3.  Using  the  Windows  Control  Panel 

Using  the  Add  Hardware  option  in  the  Windows  Control  Panel,  a  device 
driver  can  be  added  to  the  system.  This  will  be  described  in  more  detail  in  the 
section  on  driver  packaging  in  Chapter  IV. 

C.  INSTALLATION  FOR  32-BIT  AND  64-BIT  PLATFORM 

A  native  driver  package  must  be  provided  for  installation  on  different 
platforms.  A  single  32-bit  installer  can  however  be  used  to  install  the  driver 
package  on  the  different  platforms.  This  will  be  described  in  more  details  in  the 
section  on  driver  packaging  in  Chapter  IV. 

5  Some  other  possible  values  include:  SERVICE_BOOT_START  (0), 
SERVICE_SYSTEM_START  (1),  SERVICE_AUTO_START  (1),  SERVICE_DISABLED(4)  [37], 

6  Some  other  possible  values  include:  SERVICEFILESYSTEMDRIVER  (2), 
SERVICE_WIN32_OWN_PROCESS  (8),  SERVICE_WIN32_SHARE_PROCESS  (9)  [37], 
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D.  OVERVIEW  OF  THE  WINDOWS  DRIVER 

Device  drivers  mediate  communication  between  the  kernel  and  a  device. 
The  Microsoft’s  Windows  operating  system  provides  an  abstract  device  support 
interface  called  a  driver  model  to  facilitate  this  communication.  Device  drivers 
provide  the  implementation  to  this  interface  to  support  the  specific  requirements 
of  the  device.  Device  drivers  operate  much  like  services  provided  by  the 
operating  system;  they  handle  communication  between  applications  (or  other 
drivers)  and  a  device. 

1.  Kernel  Mode  Drivers 

Kernel  Mode  Drivers  run  entirely  in  kernel  space  and  are  capable  of 
communicating  and  transferring  data  directly  to  kernel  mode  components.  This 
means  that  Kernel  Mode  Drivers  can  bypass  the  mediators  lying  between  user 
and  kernel  space.  Tasks  involving  kernel  mode  components  therefore  carry  less 
overhead  when  carried  out  by  a  Kernel  Mode  Driver  as  compared  to  User  Mode 
Drivers.  Moving  a  driver  into  the  kernel  can  also  sometimes  improve 
performance.  The  flipside  of  it  all  is  that  when  a  kernel  mode  driver  fails,  it  can 
crash  an  entire  system,  whereas  the  failure  of  a  user  mode  driver  causes  only 
the  current  process  to  crash. 

2.  Kernel  Mode  Driver  Framework  (KMDF) 

The  KMDF  is  an  infrastructure  for  developing  Kernel  Mode  Drivers.  The 
framework  is  a  skeletal  device  driver  that  can  be  customized  for  specific  devices 
and  event  handling.  The  framework  drivers  are  customized  by  setting  object 
properties,  registering  callbacks  of  relevant  events,  and  using  and  including 
features  that  are  needed.  Not  only  does  KMDF  define  a  set  of  object  models,  it 
controls  the  lifetime  and  the  memory  allocation  of  these  objects. 
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a.  KMDF  Components 

Table  1  lists  the  KMDF  components  that  are  installed  part  of  WDF. 


Component 

Location 

Description 

Header  files 

wdf/inc 

Header  files  required  to  build  KMDF  drivers 

Libraries 

wdf/lib 

Libraries  for  x86,  x64,  and  Intel  Itanium 

architectures 

Sample  drivers 

wdf/src 

Sample  drivers  for  numerous  device  types;  most 
are  ported  from  Windows  Driver  Development  Kit 
(DDK)  WDM  samples 

Tools 

wdf/bin 

Tools  for  testing,  debugging,  and  installing  drivers; 
includes  the  redistributable  KMDF  co-installer, 
WdfCoinstallemn.dll 

Debugging 

symbols 

wdf/symbols 

Public  symbol  database  (.pdb)  files  for  KMDF 
libraries  and  co-installer  for  checked  and  free 
builds 

Tracing  format 

files 

wdf/tracing 

Trace  format  files  for  the  trace  messages 
generated  by  KMDF  libraries  and  co-installer 

Table  2.  KMDF  Components 

b.  Structure  of  a  KMDF  Driver 

A  KMDF  driver  is  identified  by  a  DriverEntry  function  that 
represents  the  driver’s  primary  entry  point.  Drivers  that  support  Plug  and  Play 
devices  also  have  An  EvtDriverDeviceAdd  callback.  Specific  I/O  request  events 
for  a  particu2lar  queue  can  also  be  registered  as  Evtlo*  callbacks.  A  simple 
device  will  have  the  above-described  functions  and  nothing  more.  KMDF  also 
includes  code  to  support  power  management,  Plug  and  Play  and  Windows 
Management  Instrumentations. 

3.  Description  of  the  KMDF  API 

The  Kernel  Mode  Driver  Framework  (KMDF)  object  model  defines  a  set  of 
objects  that  represent  common  driver  constructs  such  as  devices,  memory, 
queues,  I/O  requests,  and  the  driver  itself.  The  framework  objects  have  well- 
defined  life  cycles  and  contracts,  and  a  WDF  driver  interacts  with  them  through 
well-defined  interfaces  and  they  expose  programming  interfaces  that  handle  their 
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properties,  methods  that  perform  actions,  and  events  handling  through  callback 
registration  [36],  Listed  below  is  the  description  of  some  of  the  prominent 
Application  Programming  Interfaces  that  were  used  in  the  development.  This  list 
is  provided  as  a  reference  for  those  not  familiar  with  KMDF  when  studying  the 
source  code  that  is  attached  as  Appendix  E. 

1.  NTSTATUS  DriverEntry(IN  PDRIVEROBJECT  Driver  Objects,  IN 
PUNICODE_STRING  RegistryPath)  -  This  is  the  entry  point  for  the 
application  programming  of  a  Windows  device  driver.  It  is  the  first 
function  that  will  be  called  by  the  framework  [46], 

2.  WDF_DRIVER_CONFIG_INIT()  -  This  method  initializes  the 
WDF_DRIVER_CONFIG  structure  and  the  second  parameter  to  the 
method  also  registers  the  user  defined  MemReaderEvtDeviceAdd 
function  [47], 

3.  WdfDriverCreate()  -  This  method  creates  a  framework  driver  object  for 
the  calling  driver.  Specific  driver  attributes  can  also  be  defined  in  the 
user  allocated  WDF_OBJECT_ATTRIBUTES  structure  [48], 

4.  WdfDeviceCreateQ  -  This  method  creates  a  framework  device  object. 

Similar  to  the  DriverCreate  method,  specific  device  attributes  can  be 
defined.  This  method  is  called  in  the  user  defined 

MemReaderDeviceCreate  function,  which  creates  a  device  and  the 
software  resources  needed  by  the  MemReader  driver  [49], 

5.  WdfDeviceCreateDevicelnterface()  -  This  method  creates  a  device 

interface  for  a  specified  device,  i.e.  the  device  create  with 

WdfDeviceCreate.  The  device  interface  is  a  symbolic  link  that 
applications  can  use  to  access  the  device  [50], 

6.  WdfloQueueCreate()  -  This  method  creates  and  configures  an  I/O 
queue  for  a  specified  device,  i.e.  the  device  create  with 
WdfDeviceCreate.  Specific  queue  attributes,  such  as  user  defined 
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queue  callback  events,  can  also  be  defined  in  the  user  allocated 
WDF_OBJECT_ATTRIBUTES  structure  [51]. 

7.  WdfRequestRetrieveOutputMemoryO  -  This  method  retrieves  a  handle 
to  a  framework  memory  object  that  represents  an  I/O  request’s  output 
buffer.  It  is  used  to  receive  information  that  the  driver  provides  to  the 
originator  of  the  request,  such  as  a  read  request  [52], 

8.  WdfMemoryCopyFromBuffer()  -  This  method  copies  the  contents  of  a 
specified  source  buffer,  such  as  the  framework  memory  object,  into  a 
specified  memory  object’s  buffer  [53], 

9.  WdfRequestCompleteWithlnformationO  -  This  method  stores 
completion  information  and  then  completes  a  specified  I/O  request  with 
the  supplied  completed  status,  as  the  second  input  parameter,  to  the 
calling  application  [54], 

10.  WdfMemoryCopyToBuffer()  -  This  method  copies  the  contents  of  a 
specified  memory  object’s  buffer  into  a  specified  destination  buffer. 
This  is  a  reverse  WdfMemoryCopyFromBuffer  operation  [55], 

1 1 .  WdfRequestRetrievelnputBuffer()  -  This  method  retrieves  the  an  I/O 
request’s  input  buffer.  It  is  used  during  a  write  operation  to  write  to  the 
where  the  application  passes  down  information  to  the  driver.  This  is  a 
reverse  WdfRequestRetrieveOutputBuffer  operation  [56], 

A  MemReader  tag  precedes  all  the  user-defined  functions  that  are  not  part 
of  the  API.  These  include  user-defined  callback,  plug  and  play  related  and  other 
functions. 
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III.  REQUIREMENTS  AND  HIGH  LEVEL  DESIGN 


A.  BUILDING  A  KERNEL  DRIVER 

The  goal  of  this  research  is  to  build  a  Kernel  Mode  Driver  Framework 
(KMDF)  driver  for  the  Windows  Vista  operating  system  that  can  interface  with  a 
user-mode  application  and  extract  data  from  the  RAM.  The  discussion  below  will 
be  limited  to  areas  related  to  this  research. 

1.  Minimal  Requirements  to  Obtain  Developmental  Environment 

The  Windows  Driver  Foundation  (WDF)  defines  a  single  driver  model  for 
creating  object-oriented,  event-driven  drivers  for  either  kernel  mode  or  user 
mode.  The  Windows  Drivers  Kit  (WDK),  which  contains  the  Driver  Development 
Kit  (DDK),  is  the  primary  resource  needed  for  driver  development  using  the  WDF. 
The  latest  version  of  the  WDK  can  be  downloaded  from  Microsoft  Connect  [13]. 
A  Windows  Live  ID  or  Microsoft  passport  is  required  to  join  the  Microsoft 
Connect.  Detail  instructions  on  obtaining  and  installing  the  WDK  can  be  found 
on  the  Windows  Hardware  Developer  Central  (WHDC)  website  [14]. 

a.  Operating  System  Requirement 

Any  recent  version  of  Windows  can  be  used  to  develop  and  build 
KMDF  drivers  for  Windows  2000  or  later  versions  of  Windows.  The  appropriate 
build  environment  configuration  must  be  specified  when  using  the  build.exe  utility 
to  target  a  driver  for  a  particular  version  and  CPU  architecture. 

It  is,  however,  recommended  to  install,  test,  and  debug  the  driver 
on  a  system  that  is  running  the  target  version  of  Windows  and  hardware  that  is 
the  same  as  or  similar. 
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b.  Hardware  Requirements 

It  is  highly  recommended  that  the  developmental  work  configuration 
includes  a  computer  that  supports  some  form  of  Symmetric  Multiprocessing  or 
Multithreading  (such  as  hyperthreading).  This  allows  certain  type  of  bugs,  such 
as  race  conditions,  to  be  detected. 

It  is  also  highly  recommended  that  the  hardware  and  the  Operating 
System  is  matched,  i.e.,  a  64-bit  computer  that  runs  x64  version  of  Windows. 
Some  critical  errors  can  only  be  detected  on  a  64-bit  system.  For  the  purpose  of 
this  thesis,  a  32-bit  system  was  used. 

Two  computers  are  needed  to  carry  out  “live”  debugging  of  KMDF 
drivers,  one  to  host  the  debugger  and  the  other  to  host  the  driver  (and  requisite 
operating  system)  to  be  debugged.  Kernel-mode  driver  bugs  commonly  cause 
system  crashes  and  can  corrupt  the  file  system,  causing  loss  of  data.  It  is 
therefore  necessary  to  have  the  debugger  and  driver  on  separate  computers. 

2.  Development  Environment 

a.  Build  Utility 

The  Build  utility  in  the  Windows  Driver  Kit  (WDK)  invokes  the 
correct  tools  with  the  appropriate  options  to  build  your  driver.  The  Build  utility  is  a 
wrapper  around  the  Microsoft  NMAKE  utility,  so  it  handles  issues  like  checking 
dependencies  to  ensure  that  the  correct  files  are  rebuilt  after  a  change.  Building 
the  samples  provided  in  the  WDK  is  a  good  starting  ground  for  familiarizing  and 
understanding  the  Build  utility. 

b.  Build  Environment 

The  WDK  has  build  environments  for  four  versions  of  Windows 

namely: 
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•  Windows  2000 


•  Windows  Server  2003 

•  Windows  Vista  and  Windows  Server  Longhorn  and 

•  Windows  XP 

For  each  version  of  Windows,  there  is  a  checked  and  free  build 
environment  for  each  CPU  type.  Drivers  compiled  in  the  checked  build 
environment  will  have  many  of  the  optimizations  disabled  and  conditional  code 
for  debugging  included.  Production  drivers  are  compiled  in  the  free  build 
environment  will  have  debug  code  disable  and  will  contain  optimized  code. 

c.  Editor  and  Integrated  Development  Environment  (IDE) 

The  source  code  in  this  research  was  edited  using  the  Windows 
wordpad.exe.  Microsoft  Visual  Studio  can  however  be  used  as  both  an  editor 
and  an  IDE  for  driver  development.  It  would  require  all  Microsoft  Visual  Studio 
options  to  be  configured  to  match  those  of  WDK  and  it  should  be  configured  to 
invoke  the  build.exe  utility  (provided  by  WDK)  using  a  batch  command  line. 
However,  Microsoft  Visual  Studio  was  not  used  in  this  research.  A  more  detailed 
discussion  on  configuring  Microsoft  Visual  Studio  for  driver  development  can  be 
found  on  the  OSR  Online  [58]  and  Hollis  Technology  Solution  [59]  website. 

3.  Debugging  Tools 

a.  Windows  Debuggers 

Microsoft  provides  a  32-bit  and  64-bit  set  of  Debugging  Tools  [22] 
for  debugging  the  operating  system,  applications,  services,  and  drivers  that  run 
on  the  operating  system.  Out  of  the  four  debuggers  provided  by  the  installation 
package,  only  Microsoft  Kernel  Debugger  (KD)  and  Microsoft  Windows  Debugger 
(WindDbg)  are  capable  of  debugging  kernel-mode  programs  and  drivers. 
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The  setup  of  kernel-mode  debugging  is  an  elaborate  one  that 
requires  both  hardware  and  software  configuration.  KD  and  WinDbg  are  both 
powerful  debuggers  that  are  capable  of  monitoring  the  behavior  of  the  operating 
system  itself  and  full  source  level  debugging  for  Windows  kernel,  kernel-mode 
drivers  and  system  services  respectively. 

b.  Debug  Output  Viewer  (DebugView) 

DebugView  [23]  is  an  application  for  monitoring  the  debug  outputs 
on  your  local  system,  or  any  computer  on  the  network  that  is  reachable  via  TCP/ 
IP.  It  is  capable  of  displaying  both  kernel  mode  and  Win32  debug  outputs  that 
are  generated  by  applications  and  device  drivers.  DebugView  will  capture  the 
output  of  the  following  functions: 

•  Win32  OutputDebugString 

•  Kernel-mode  DbgPrint 

•  All  kernel-mode  variants  of  DbgPrint  implemented  in 
Windows  XP,  Server  2003  and  Vista 

DebugView  also  extracts  kernel-mode  debug  output  generated 
before  a  crash  if  it  was  capturing  at  the  time  of  the  crash. 

In  Windows  Vista,  DbgPrint  defaults  to  the  DEFAULT  debug 
component  and  the  default  settings  for  this  component  is  to  hide  all  outputs.  To 
display  the  DbgPrint  outputs,  go  to  the  registry  path  at 
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SessionManager 
\  add  a  new  key  called  “Debug  Print  Filter”  and  add  the  following  value 
“DEFAULT” :  REG_DWORD  :  OxFFFFFFFF  and  then  reboot. 

DebugView  is  a  simple  tool  that  requires  little  setup  before  it  is 
ready  for  use.  It,  however,  requires  elevated  privileges  to  display  kernel  debug 
outputs.  This  tool  is  used  extensively  in  the  debugging  during  developmental 
work  due  to  its  simplicity  and  ease  of  use. 
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B.  DESIGN  COMPARISON  TO  SIMILAR  TOOLS 


Several  free  and  commercial  tools  are  capable  of  creating  a  memory 
image  of  the  data  contained  in  RAM.  This  includes  the  DD  released  by  ManTech 
[16],  Helix  released  by  eFense  [8]  and  the  Forensics  Acquisition  Utilities  [7]  by 
George  M  Garner.  Microsoft  changed  the  way  memory  is  accessed  on  Windows 
Vista  and  has  moved  the  access  from  user  space  into  kernel  space.  The  three 
tools  all  require  elevated  privileges  for  them  work  to  on  Windows  Vista. 

The  source  code  and  design  of  the  version  1.2  of  the  ManTech  DD  tool 
was  studied  in  more  detail  for  literary  and  comparison  purposes.  The  package 
released  in  version  1.2  includes  an  executable  application  file  and  a  device 
driver.  Similarly,  the  goals  of  this  development  will  include  an  executable 
application  and  a  device  driver.  The  application  needs  to  be  started  in  a 
command  prompt  that  has  elevated  privileges. 

Once  the  DD  application  starts,  it  determines  if  it  is  executed  in  the  correct 
environment,  such  as  operating  system  and  architecture.  It  then  proceeds  to 
load  the  device  driver  that  came  with  the  package  and  starts  it  as  a  system 
service.  The  device  driver  opens  a  handle  to  the  physical  memory  segment. 
This  handle  is  passed  to  the  application  that  utilizes  it  to  create  an  image  of  the 
RAM.  Since  the  handle  to  the  physical  memory  section  is  being  used  in  the 
application,  it  requires  elevated  administrator  privileges. 

One  of  the  objectives  of  this  research  is  to  show  that  utilizing  an 
appropriate  device  driver;  a  user  space  application  can  also  be  used  to  create  an 
image  of  RAM.  For  the  purpose  of  this  research,  a  kernel  mode  device  driver 
was  developed  and  loaded  into  the  kernel.  The  driver  opens  a  handle  to  the 
physical  memory  segment  and  when  the  user  mode  application  interacts  with  the 
device  driver,  the  driver  maps  sections  of  the  physical  memory  into  the  process’s 
virtual  address  space.  The  driver  then  copies  the  information  from  the  physical 
memory  into  the  buffer  of  the  application.  The  application  then  saves  the  data  on 
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the  buffer  into  an  image  file  in  a  filesystem  present  on  the  computer  system. 
Figure  1  is  a  graphical  representation  of  this  process. 
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IV.  IMPLEMENTATION 


A.  IMPLEMENTATION  OBJECTIVE  REVIEW 

Part  of  the  objective  of  this  research  is  to  develop  a  tool  that  is  capable  of 
extracting  the  contents  of  the  volatile  RAM  from  a  Windows  Vista  system.  Since 
the  proposal  for  this  research  was  approved,  ManTech  International  Corporate 
[15]  has  released  a  similar  open  source  tool  [16]  for  capturing  memory  on 
Windows  Vista  and  Windows  2003  Server. 

The  tool  release  by  ManTech  consisted  of  a  device  driver  and  a  separate 
Windows  application.  The  device  driver  does  not  need  to  be  installed  on  the 
system  before  the  application  is  run.  However,  since  a  driver  is  being  installed, 
administrative  privileges  are  required  for  the  user  running  the  tool  . 

The  purpose  of  the  research  is  therefore  to  develop  a  driver  that  can  be 
preinstalled  on  Windows  Vista  system  such  that  a  user  mode  application  can  be 
used  to  extract  a  copy  of  the  memory  when  it  is  needed,  providing  organizations 
a  method  of  incident  preparation  in  addition  to  incident  response. 

Such  a  driver  can  be  preinstalled  on  systems  that  are  vulnerable  to 
attacks,  extracting  an  image  of  the  RAM  will  have  significant  forensic  benefits. 
An  example  would  be  honeypots  that  have  been  setup  by  system  administrators. 

B.  IMPLEMENTATION  STRATEGY 

1.  Windows  Driver  Kit  (WDK)  Samples 

Besides  the  development  environment,  there  is  a  wealth  of  useful 
information  that  is  distributed  together  with  the  WDK.  One  such  source  is  the 
samples  that  are  included  with  each  distribution.  The  different  samples  not  only 
provide  a  starting  point  for  understanding  the  User  Mode  Driver  Framework 
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(UMDF)  [17]  and  the  Kernel  Mode  Driver  Framework  (KMDF)  [18]  but  also  the 
different  object  models  and  functionalities. 

The  sample  codes  are  all  “ready  to  compile”  in  the  WDK  development 
environment  and  no  modification  to  the  system  or  any  files  is  required. 
Depending  on  the  chosen  type  of  build  environment  (checked  or  free)  for 
compilation,  the  output  files  will  be  built  accordingly.  The  built  driver 
(<sample>. sys)  be  installed  using  a  Co-installer  that  should  come  with  the 
distribution  of  the  WDK.  This  will  be  described  in  more  detail  in  a  later  chapter. 

The  sample  codes  are  therefore  good  starting  points  for  developmental 
work  to  begin.  This  greatly  reduces  the  learning  curve  of  driver  development  and 
environment  setup.  The  samples  were  studied  and  the  one  with  the  closest 
structure  and  functionality  that  fits  the  purpose  of  this  research  was  selected  to 
be  the  starting  point  of  development  work.  Modifications  were  made  to  the 
sample  code  to  fulfill  the  functionality  requirement  of  this  research. 

2.  The  Echo  Sample 

The  very  nature  of  the  driver  requires  access  to  the  physical  memory  and 
some  form  of  I/O  between  a  kernel  mode  driver  and  a  user  mode  application 
limited  the  workable  set  of  samples  to  those  that  made  use  of  the  KMDF.  The 
Echo  sample,  though  not  the  only  sample  that  fulfilled  these  two  requirements, 
was  chosen  for  its  simplicity  and  elegance. 

The  driver  in  the  echo  sample  demonstrates  the  use  of  a  default  I/O 
queue,  it  requests  start  events,  cancellation  events,  and  a  synchronized  Deferred 
Procedure  Call  (DPC).  The  modifications  were  mainly  limited  to  how  the  driver 
interacted  with  the  physical  memory  and  how  the  data  read  from  the  physical 
memory  is  transferred  onto  the  I/O  queue.  The  full  source  code  can  found  in 
Appendix  C. 
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3.  Development  Process 


a.  Functional  Description 

The  driver  is  an  interface  between  the  application  and  the  physical 
memory  device.  As  such,  it  has  to  be  capable  of  accessing  the  data  on  the 
physical  memory  device  and  transferring  it  to  the  user  mode  application.  The 
driver  acts  as  an  intermediary  that  transfers  data  from  the  physical  memory  to  the 
buffer  of  the  user  mode  application.  The  user  mode  application  will  need  to  write 
the  data  it  receives  from  the  driver  into  a  file. 

Before  the  driver  can  gain  access  to  the  data  on  the  physical 
memory,  it  will  need  to  get  a  handle  to  the  physical  memory  device.  This  can  be 
accomplished  by  the  ZwOpenSection  [24]  function  call  to  the 
\Device\PhysicalMemory  [25]  location.  This  handle  is  used  by  the  driver  during 
subsequent  read  events,  EvtloRead,  where  different  sections  of  the  physical 
memory  section  will  be  mapped  into  the  virtual  address  space  of  the  application 
that  invoked  the  driver.  The  complete  source  code  is  attached  as  Appendix  E. 

b.  Development  Cycle 

The  DbgPrint  function  is  used  extensively  in  the  driver  code  for 
verification  and  debugging.  The  driver  is  modified  incrementally  either  by  adding 
new  functionalities  such  as  retrieving  a  handle  to  the  physical  memory  and  by 
trimming  the  unnecessary  functions  such  as  the  timer  for  Deferred  Procedure 
Calls  from  the  sample  code. 

As  the  driver  is  modified,  the  older  version  of  the  driver  is 
uninstalled  and  a  new  version  is  installed  on  the  target  system  and  tested. 
Installation  of  driver  is  done  through  the  Add  Hardware  menu  in  the  Control 
Panel.  It  is  worth  noting  that  when  a  driver  is  uninstalled,  through  the  Device 
Manager  in  the  Control  Panel,  only  the  devnode  associated  with  the  device  is 
removed.  The  device  instance  no  longer  exists  but  the  device  package  is  still  in 
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the  driver  store.  When  the  driver  code  is  modified  and  subsequently  rebuilt, 
there  will  be  an  updated  version  of  the  .sys  driver  file.  The  information  in  the  INF 
file  is  however  unchanged  and  remains  the  same  as  prior  compilations.  When 
the  newly  built  package  is  installed  (Control  Panel  >  Add  Hardware),  Setup 
simply  re-associates  the  devnode  with  the  previous  version  of  the  driver  package 
in  the  driver  store  by  recreating  the  appropriate  registry  entries. 

To  ensure  that  the  updated  version  of  the  driver  package  is 
installed  correctly,  the  driver  package  must  be  deleted  from  the  driver  store 
during  uninstallation.  This  can  be  done  by  selecting  the  “Delete  the  driver 
software  for  this  device”  checkbox  during  the  uninstallation  process  (Control 
Panel  >  System  >  Device  Manager).  The  WDF  co-installer  DLL  file  must  be  in 
the  same  directory  as  the  INF  and  driver  (.sys)  file  when  the  updated  driver  is 
being  installed. 

Once  the  updated  driver  package  has  been  installed,  the  debug 
outputs  are  captured  using  DebugView  and  the  application  debug  output  are 
printed  to  the  console.  Together  with  the  information  saved  in  the  dump  file 
(RAM  image),  the  correctness  of  the  driver  and  the  application  is  verified.  The 
cycle  of  modification,  rebuilding,  uninstallation,  reinstallation  and  testing  is 
continued  until  the  driver  and  the  application  are  verified  to  be  working  correctly. 

C.  DEBUGGING 

Debugging  a  KMDF  driver  for  beginners  is  a  tricky  business.  Since  kernel 
mode  drivers  execute  in  a  lower  and  more  privileged  level  of  the  operating 
system,  they  do  not  have  straightforward  access  to  the  user  mode  components 
such  as  the  standard  output.  Debug  and  print  statements  are  therefore  not  as 
easily  displayed  as  in  user  mode  applications.  The  ramifications  of  any  violation 
in  kernel  mode  components  are  also  much  greater  and  they  are  almost  certain  to 
be  met  with  a  bug  check  (system  crash).  Operating  in  kernel  space  also  means 
that  the  components  will  need  to  cater  to  operating  features  such  as  paging  and 
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interaction  with  other  system  drivers.  A  careless  mistake  can  sometimes  be 
propagated  down  the  chain  and  be  amplified  into  a  big  problem. 

1.  Printing  Debug  Statements 

Printing  output  statements  represents  the  simplest  debugging  aid. 
DebugView  is  therefore  the  most  widely  used  debugging  tool  during  the 
development.  The  DbgPrint  API  call  be  made  from  anywhere  within  the  driver 
code  and  it  will  be  displayed  with  drivers  built  in  the  check  and  free 
environments.  The  DbgPrint  function  [26]  takes  in  a  variable  argument  list  much 
like  its  user  mode  counterpart  -  printf,  and  can  be  formatted  to  display  variable 
values. 

DebugView  was  used  at  all  times  during  the  testing  and  debugging  phase. 
This  ensured  that  debug  statements  could  be  retrieved  later  in  the  event  of  an 
unexpected  bug  check.  To  retrieve  the  debug  statements  prior  to  a  bug  check, 
use  the  process  dump  file  from  the  File  option  in  top  menu  bar  and  browse  to  and 
select  the  memory  dump  file  created  by  the  bug  check. 

2.  Analyzing  the  Memory  Dump  File 

When  a  bug  check  is  issued,  a  crash  dump  file  will  be  created  proved  that 
the  system  is  configured  to  create  it.  To  configure  for  a  full  memory  dump  during 
a  bug  check,  go  to  the  System  Menu  in  the  Control  Panel  (Hold  Windows  key  + 
Pause/  Break).  In  the  “Advance”  tab  in  the  “Advance  System  Settings”  menu, 
select  “Settings”  for  “Startup  and  Recovery”,  choose  a  “Complete  memory  dump” 
in  the  “System  failure”  section.  The  memory  dump  file  contains  a  snapshot  of 
useful  low-level  information  about  the  system  that  can  be  used  to  debug  the  root 
cause  of  the  bug  check. 

WinDbg  was  used  to  analyzed  the  memory  dump  files  when  the 
MemReader  driver  caused  any  system  crash.  The  stack  traces  and  device  driver 
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that  led  to  the  crash  can  be  inspected.  The  appropriate  symbol  package  [44] 
need  to  be  installed  before  trace  information  of  the  system  drivers  is  observable. 

D.  DEVICE  DRIVER  PACKAGE 

A  driver  package  consists  of  all  the  hardware  and  software  components 
that  are  needed  to  support  the  device  under  Windows  [21].  Since  the  driver  that 
was  developed  in  this  research  is  a  pure  functional  driver  not  associated  with  any 
hardware,  the  driver  package  we  create  will  only  consist  of  software  components. 
This  includes  the  driver  files  and  the  installation  files. 

1.  Driver  Files  (.sys  file) 

The  driver  files  provide  the  I/O  interface  between  the  application  and  the 
physical  memory.  The  driver  files  are  usually  in  the  form  of  a  dynamically  linked 
library  with  a  .sys  file  extension.  Upon  installation  of  the  driver,  the  .sys  file  is 
copied  to  the  %windir%\system32\drivers\  directory. 

2.  Installation  Files 

These  files  are  needed  for  driver  installation.  Drivers  can  be  installed 
through  the  Add  Hardware  menu  in  the  Control  Panel. 

a.  Device  Setup  Information  file  (.inf  file) 

A  .inf  file  contains  information  that  the  system  Setup  components 
use  to  install  support  for  the  device  driver.  The  registry  entry  information  related 
to  the  driver  makes  up  part  of  the  .inf  file.  The  .inf  file  of  the  driver  package  for 
this  thesis  is  attached  as  Appendix  E. 

b.  Co-installers 

A  co-installer  is  a  Microsoft  Win32  dynamic-link  library  that  assists 

in  device  driver  installation  on  Windows  NT-based  operating  systems.  A  different 

co-installer  file  is  needed  for  installing  the  checked  build  of  a  driver.  The  free 
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version  co-installer  should  not  be  packaged  interchangeably  with  the  checked 
version.  A  checked  build  of  a  KMDF  driver  cannot  be  installed  on  a  free  build  of 
the  OS. 

These  KMDF  redistributable  binaries  are  architecture  dependent 
and  are  all  distributed  as  part  of  the  Windows  Driver  Kit.  They  can  be  found  in 
the  <  WDKInstallation>\<BuildNumber>\red\st\\Ndf\<architecture>  directory. 

c.  Driver  Catalog  file  (.cat  file) 

A  .cat  file  contains  a  cryptographic  hash  of  each  file  in  the  driver 
package.  Windows  uses  these  hashes  to  verify  that  the  package  has  not  been 
altered  after  it  has  been  published.  The  software  publisher  offers  authenticity  by 
digitally  signing  all  the  files  in  the  driver  package. 

The  mandatory  kernel-mode  code-signing  policy  applies  to  all 
kernel-mode  software  and  drivers  for  x64-based  systems  that  are  running 
Windows  Vista.  Kernel-mode  signatures  are  also  verified  on  32-bit  system  but 
an  administrator  has  the  capability  of  installing  an  unsigned  driver. 

E.  PROBLEMS  ENCOUNTERES 

1.  Windows  Driver  Development 

a.  Windows  Operating  System 

Despite  having  more  than  ninety  percent  of  the  market  share  for 
commercial  consumer  Operating  Systems  [27],  Microsoft’s  Windows  has  perhaps 
the  least  open  literature  available  for  understanding  how  the  clock  works  beneath 
its  desktop  graphical  user  interface;  this  is  Microsoft’s  attempt  to  protect  the 
Microsoft  Windows’  proprietary.  Since  the  MemReader  driver  interacts  with  the 
Physical  Memory  segment,  a  more  thorough  understanding  of  the  Window’s 
Memory  Model  is  needed  to  develop  a  smooth  working  driver. 
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When  mapping  the  physical  memory  using  the  native  windows  API 
call,  ZwMapViewOfSection  [28],  a  page  protection  attribute  needs  to  be  provided. 
This  specifies  the  type  of  protection  for  the  region  of  initially  committed  pages. 
This  attribute  determines  the  memory  type  marked  by  Windows  in  a  page  table 
entry.  The  memory  type  tells  the  processor  how  to  handle  accesses  to  a  page. 
This  affects  how  the  memory  locations  are  read  and  written  from  the  different 
caches  (LI,  L2  and  L3  cache).  The  behavior  of  the  Operating  System  becomes 
indeterminate  when  a  single  physical  page  is  mapped  to  more  than  one  virtual 
address  space  with  conflicting  memory  type  [45], 

The  anomaly  described  above  exists  in  versions  of  the  Windows 
Operating  system  before  Windows  XP.  Versions  of  Windows  after  XP  check  for 
page  mapping  with  different  memory  types.  An  attempt  to  map  a  page  with  a 
second  memory  type  will  result  in  a  failure  with  the 
STATUS_CONFLICTING_ADDRESSES  (0x00000018  [29]  [30])  error  message. 

b.  Driver  Development  and  its  API 

One  of  the  design  goals  of  the  Windows  Driver  Foundation  (WDF) 
[31],  is  to  provide  a  consistent  model  to  ensure  that  knowledge  gained  in  the 
development  of  one  driver  can  be  transferred  across  device  classes.  This  does 
not  however  reduce  the  copious  amount  of  familiarization  that  one  needs  before 
being  able  to  embark  on  driver  development.  With  this  being  said,  the  bulk  of  the 
information  available  on  Windows  driver  development  can  only  be  found  at  the 
MSDN  [32]  and  WHDC  [14]  website.  Each  topic  in  driver  development  is  written 
and  maintained  in  separate  papers.  As  such,  there  is  largely  no  consistency 
amongst  the  content  of  the  papers  and  not  all  the  papers  are  updated  with  the 
most  current  material. 

The  community  involved  in  driver  development  is  also  largely  a 
small  one.  Sources  of  information  are  scarce  especially  when  it  comes  to  the 
specifics  of  dealing  with  the  Driver  Development  Framework  or  kernel 
programming  in  Windows.  The  situation  is  not  helped  by  the  changes  that  are 
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brought  about  with  each  new  version  of  the  Windows  Operating  system.  Each  of 
the  different  versions  of  the  Windows  kernel  operates  slightly  differently  and  the 
kernel  APIs  are  subtly  different  in  each  of  the  versions.  Since  many  kernel 
drivers  are  developed  to  support  commercial  hardware  products,  it  may  not  be  in 
a  company’s  best  interest  to  aide  a  competing  company  in  software 
development. 

2.  Testing  and  Debugging 

The  complexity  and  the  intertwined  nature  of  how  device  drivers  depend 
on  each  other  to  operate,  with  many  device  drivers  working  together  and 
depending  of  each  other,  greatly  complicate  the  job  of  testing  and  debugging  a 
device  driver.  It  is  difficult  to  determine  the  source  of  error  and  explain  anomalies 
and  erroneous  behavior  during  testing. 

a.  Blue  Screen  of  Death  (BSoD) 

It  is  often  difficult  to  recover  from  errors  and  faults  in  an  Operating 
System’s  kernel  components.  Faults  or  errors  usually  result  in  a  system  crash  or 
in  Microsoft  Windows  Operating  System’s  case,  a  Blue  Screen  of  Death  (BSoD). 
This  is  also  sometimes  referred  as  a  system  halt  or  bug  check.  When  this 
happens,  Windows  halts  its  operations  and  creates  a  memory  dump  file  with 
information  on  the  state  of  the  system  when  the  error  occurred.  There  is  also 
some  information  displayed  on  the  Blue  Screen  that  describes  the  error  [33], 

The  first  section  shows  the  actual  error  message.  The  error 
messages  may  give  a  clue  regarding  the  source  of  the  error,  but  messages  like 
BAD_POOL_HEADER  are  cryptic  and  they  do  not  really  help  with  pin  pointing 
the  source  of  error.  Specific  technical  information  regarding  the  crash  can  be 
found  at  the  bottom  of  the  screen  in  a  section  aptly  titled  Technical  Information’. 

Figure  2  is  a  screen  capture  of  a  BSoD  for  a  Page  Fault  In  Non 
Paged  Area  bug  check.  The  hexadecimal  code  that  follows  the  word  ‘STOP’  in 

the  Technical  Information  section  is  the  bug  check  code  used  by  the  Operating 
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System.  The  four  parameters  that  follow  contain  specific  information  regarding 
this  instance  of  bug  check.  The  name  of  the  component,  if  available,  that  caused 
this  error  is  also  listed.  The  SPCMDCON.SYS  is  the  device  driver  that  caused 
the  bug  check  in  Figure  2.  The  bug  check  code  can  be  used  as  a  reference  key 
[34]  to  find  specific  information  on  each  parameter. 


A  problem  has  been  detected  and  Windows  has  been  shut  down  to  prevent  damage 
to  your  computer. 

The  problem  seems  to  be  caused  by  the  following  file:  SPCMDCON.SYS 
PAG  E_FAU LT_I N_NON PAG  E  D_AR EA 

if  this  is  the  first  time  you've  seen  this  stop  error  screen, 
restart  your  computer,  if  this  screen  appears  again,  follow 
these  steps: 

check  to  make  sure  any  new  hardware  or  software  is  properly  installed, 
if  this  is  a  new  installation,  ask  your  hardware  or  software  manufacturer 
for  any  windows  updates  you  might  need. 

if  problems  continue,  disable  or  remove  any  newly  installed  hardware 
or  software.  Disable  bios  memory  options  such  as  caching  or  shadowing, 
if  you  need  to  use  safe  Mode  to  remove  or  disable  components,  restart 
your  computer,  press  F8  to  select  Advanced  startup  Options,  and  then 
select  safe  Mode. 

Technical  information: 

**»'  STOP:  0x00000050  (0XFD3094C2, 0x00000001, 0XFBFE7617, 0x00000000) 


k**  SPCMDCON.SYS  -  Address  FBFE7617  base  at  FBFE5000,  Datestamp  3d6dd67c 


Figure  2.  Blue  Screen  of  Death:  Page_Fault_ln_Non_Paged_Area 


b.  ZwMapViewOfSection  [28] 


The  ZwMapViewOfSection  routine  maps  a  view  of  a  section  of  the 
Physical  Memory  into  the  virtual  address  space  of  a  subject  process.  Ten 
parameters  need  to  be  provided  to  create  a  successful  mapping. 
ZwMapViewOfSection  returns  a  NTSTATUS  value  to  report  on  the  status  of  the 
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mapping  operation.  ZwMapViewOfSection  is  a  nontrivial  mapping  function  and 
an  unsuccessful  mapping  can  be  due  to  many  reasons.  It  can  be  exasperating 
when  trying  to  determine  the  cause  of  a  failed  operation. 

There  are  many  return  values  for  NTSTATUS  that  will  help 
determine  the  cause  of  an  unsuccessful  mapping.  It  is  important  to  capture  the 
specific  returned  status  in  the  event  of  an  unsuccessful  mapping.  The 
description  of  each  specific  error  code  can  be  found  in  the  ntstatus.h  file  in  the 
win32api  package  and  it  is  readily  available  on  the  Internet  [30],  It  is  useful  to 
include  the  error  code  and /  or  the  error  description  when  searching,  for  example 
on  Google.com,  to  find  the  meaning  of  an  error  return  value  and  a  possible 
approach  to  mitigate  the  error. 

In  the  earlier  stages  of  testing,  there  was  a  consistent  discrepancy 
in  the  location  of  the  first  appearance  of  the  known  string.  These  known  strings 
are  deliberately  injected  into  RAM  as  markers.  They  will  be  discussed  in  more 
detail  in  the  chapter  on  test  methodology.  There  was  always  a  misalignment  of  8 
times  the  TX_BLOCK_SIZE  constant  (see  public. h  in  Appendix  E).  Upon  further 
examination,  this  misalignment  was  attributed  to  the  failed  mappings  of  the 
ZwMapViewOfSection.  In  the  event  of  a  read  failure  from  the  MemReader  driver, 
the  MemReader  application  will  skip  this  write  operation  for  the  cycle  and 
proceed  on  to  the  next  offset.  Instead  of  skipping  the  write  operation,  the 
MemReader  will  need  to  pad  the  image  file  with  NULL  bytes7  so  that  the  two 
images  (the  control  image  created  by  ManTech’s  DD  or  MDD  and  the  image 
created  by  MemReader)  maintained  offset  synchronization.  This  also  leads  to 
the  use  of  the  same  TX  BLOCK  SIZE  as  MDD. 


7  This  operation  is  similar  to  the  conv=sync  option  in  the  linux  tool  dd. 
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V.  TEST  METHODOLOGY 


A.  TESTING  OVERVIEW 

The  content  of  RAM  is  changing  every  minute,  with  or  without  any  human 
intervention,  as  many  background  processes  are  executing  to  support  the 
Operating  System.  When  the  any  tool  or  application  is  executed,  it  too  will  be 
loaded  into  memory  thereby  changing  the  contents  of  RAM. 

The  testing  to  show  that  both  the  developed  driver  and  application  is 
extracting  a  correct  image  of  RAM  can  be  split  into  two  parts  as  described  the 
following  section. 

B.  TESTING  FOR  THE  PRESENCE  OF  DATA 

A  certain  amount  of  known  information  was  injected  into  memory  and  the 
image  created  by  the  developed  driver  (and  tool)  was  inspected  for  the  presence 
of  that  information  .The  simplest  form  of  information  to  inject  and  detect  would  be 
ASCII  encoded  strings. 

This  can  be  achieved  by  opening  the  notepad  application  and  typing  many 
instances  of  a  string  of  characters  on  a  Windows  system  that  is  loaded  with  the 
MemReader  driver.  The  binary  representation  of  the  repeated  string  must  be 
stored  in  some  part  of  memory.  Without  exiting  the  notepad  application,  start  the 
MemReader  tool  to  create  an  image  of  the  system’s  RAM.  If  the  MemReader 
has  correctly  imaged  the  RAM,  the  repeated  string  of  characters  should  also  be 
found  in  the  created  image  file. 

The  image  file  can  then  be  inspected  with  a  HEX/  ASCII  editor  [11]  [12] 
that  is  capable  of  displaying  both  the  binary  form  of  the  data  and  any  ASCII 
encoded  information.  If  the  extraction  and  creation  of  the  image  file  is  done 
correctly,  the  repeated  string  of  characters  should  be  correctly  displayed  in  the 
editor. 
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C.  TESTING  BY  COMPARISON 

The  testing  approach  described  in  Section  B  in  this  chapter  is  a  simple, 
functional  test  to  prove  that  the  driver  and  imaging  tool  is  working.  However,  the 
test  only  shows  that  MemReader  has  correctly  imaged  the  part  of  memory  used 
by  an  active  process  (notepad).  In  comparison  with  the  size  of  memory  in 
systems  today,  application  memory  only  accounts  for  a  small  percentage  of  the 
memory,  and  does  not  provide  for  any  method  of  verifying  addresses,  page 
alignment,  etc. 

A  more  definitive  method  of  testing  is  by  comparing  two  memory  images, 
one  that  is  created  by  a  known  good  means  and  the  other  by  MemReader.  Since 
the  content  of  RAM  is  consistently  changing  due  to  a  “sliding  window”  effect  [3],  it 
will  be  impossible  to  have  two  images  that  have  a  100%  match.  A  high  degree  of 
congruency  between  the  images  is  however  expected. 

1.  RAM  Image  Obtained  Using  a  Known  Good  Tool 

For  the  purpose  of  this  research,  the  comparison  was  made  with  the 
image  created  by  the  ManTech  DD  (MDD)  tool.  The  ManTech  DD  was  an 
obvious  candidate  for  the  following  reason: 

a.  The  source  code  was  accessible  and  understood  so  that  there  was  no 
ambiguity  about  the  format  of  the  data  image  created  by  MDD. 

b.  To  date,  not  many  other  software  tools  are  available  for  creating  an 
image  of  the  RAM  for  the  Windows  Operating  System. 

To  ensure  minimal  difference  between  the  two  images,  created  using 
MemReader  and  the  ManTech  DD,  the  system  should  be  very  lightly  loaded 
during  the  test  and  the  two  tools  should  be  run,  one  immediately  followed  by  the 
other.  A  more  detailed  discussion  on  the  expected  content  of  memory  is  done  in 
the  next  chapter. 
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2. 


RAM  Image  Obtained  Using  VMware 


The  use  of  VMWare  [10]  creates  a  pristine  image  of  the  Operating  System 
when  the  Virtual  Machine  (VM)  is  paused.  If  the  VM  is  loaded  with  the 
MemReader  driver,  an  image  of  the  RAM  can  be  captured  immediately  after  the 
VM  is  restarted.  This  ensures  minimal  changes  between  the  two  images.  Since 
this  method  does  not  require  any  instrumentation  in  the  VM  itself  (the  action  is 
entirely  external),  the  delta  between  the  VMWare  memory  file  and  the  acquired 
file  are  expected  to  be  smaller  than  the  delta  present  in  method  1 . 

D.  TESTING  ENVIRONMENT  AND  SETUP 

The  test  target  is  a  Dell  Optiplex  GX280  Series  system  running  on  the 
Windows  Vista  Business  Operating  System.  The  machine  specification  is  listed 
in  Table  3.  The  RAM  capacity  was  obtain  programmatically  using  Window  native 
API  GlobalMemoryStatusEx  [42], 


Description 

Processor 

Intel®  Pentium®  4  CPU  3.40GHz  3.39GHz 

Memory  (RAM) 

2037.52MB 

System  Type 

32-bit  Operating  System 

Operating  System 

Windows  Vista  Business 

Table  3.  Test  Target  System  Specification 

In  an  ideal  situation,  images  should  be  created  by  the  several  testing 
methods  so  that  the  information  of  the  physical  memory  is  the  same  for  each 
method.  A  set  of  procedure  are  followed  in  order  to  ensure  that  the  data  in  the 
physical  memory  is  as  similar  as  possible  on  each  test  of  the  system  when  the 
different  RAM  images  are  created.  Upon  system  start  up,  the  same  user-account 
is  used.  The  system  is  left  to  idle  for  a  five-minute  period  for  the  system 
applications  and  service  to  be  loaded,  this  includes  the  MemReader  service 
driver.  A  text  file  containing  repeated  known  strings  as  described  in  subsection  B 
is  opened  using  notepad.  The  RAM  image  file  is  first  created  using  the 
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ManTech’s  DD  tool.  Subsequently,  another  RAM  image  is  created  using  the 
MemReader  application.  For  more  detailed  information  on  the  procedures  for 
creating  a  RAM  image  see  Appendix  D. 


38 


VI.  RESULTS  AND  ANALYSIS 


A.  DEVELOPMENT  RESULTS 

The  MemReader  device  driver  developed  is  still  an  unfinished  product. 
There  are  still  a  few  bugs  and  there  are  still  some  issues  with  its  stability  that  can 
be  further  explored  in  future  works.  MemReader  requires  some  fine-tuning  and 
arguably  better  integration  with  the  Windows  operating  system  in  order  to 
achieve  enough  stability  for  production  use.  The  testing  methodology  proposed 
in  the  previous  chapter,  therefore,  cannot  currently  be  strictly  adhered  to. 

The  development  still  yielded  an  installable  MemReader  driver  package 
and  a  user-mode  MemReader  application  that  utilizes  and  interfaces  with  the 
MemReader  driver  and  extracts  information  from  the  RAM.  The  MemReader 
driver  installs  under  the  Class  Name  Tools’  with  Service  Description  name 
“Memory  Reader  Service’,  specified  in  the  memreader.inx  file  (see  Appendix  E). 

The  MemReader  application  takes  in  two  parameters,  namely  the  file 
name  of  the  image  in  which  the  extracted  information  will  be  saved  and  an 
optional  offset  (in  Megabytes)  where  the  driver  will  start  reading  memory 
information  from.  The  following  example  would  create  an  image  file  name 
test.bin  from  starting  one  megabyte  into  memory: 

>MemReader.exe  test.bin  1 

The  first  observation  from  running  the  MemReader  application  on  a 
system  installed  with  the  MemReader  Service  driver  was  that  the  application  was 
unable  to  extract  information  at  the  sixth  megabytes  offset.  This  happened  in  all 
the  test  runs  and  the  MemReader  application  fails  with  a  system  error  487.  A 
simple  lookup  [38]  explains  that  the  application  made  an  “attempt  to  access  (an) 
invalid  address”.  Debugging  the  MemReader  service  driver  revealed  that  the 
routine  ZwMapViewOfSection  has  failed  with  a  NTSTATUS  error  code 
0xC0000018  -  STATUS  CONFLICTING  ADDRESSES.  The  MemReader 
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application  ignores  this  error  and  continues  extracting  information  from  other 
memory  locations  by  skipping  this  offset.  The  MemReader  driver  is  however  still 
somewhat  unstable  and  can  cause  indeterminate  system  crashes  during  the 
process  of  extracting  data  from  RAM.  The  cause  of  these  crashes  could  not  be 
determined. 

B.  MODIFIED  TESTING  METHODOLOGY 

A  RAM  image  extracted  using  the  ManTech’s  DD  (MDD)  tool  was  created 
and  used  as  a  control  for  which  the  other  extracted  image,  using  the  MemReader 
application  and  MemReader  service  driver,  were  verified  against.  There  is  still  a 
stability  issue  with  the  MemReader  service  driver  and  it  causes  indeterminate 
system  halts  during  the  creation  of  the  test  RAM  image.  Although  a  complete 
image  of  RAM  is  not  captured,  the  lower  regions  (offset)  are  captured8  and  can 
be  used  for  verification  purpose. 

Two  text  files  containing  the  repetition  of  two  different  known  strings  are 
opened  during  testing.  The  two  text  files,  that  are  opened  using  two  separate 
instances  of  the  notepad  application,  will  occupy  two  separate  region  of  memory. 
This  was  a  useful  marker  for  the  verification  of  the  created  test  image.  The 
details  of  the  two  text  files  are  as  specified  in  Table  4. 


File  Name 

TestFile1.txt 

TestFile2.txt 

File  Size 

16,391KB 

16,393KB 

Repeated  String 

This  is  an  usually  short  string 
for  such  a  big  file. 

the  quick  brown  fox  jumped 
over  the  lazy  dog. 

String  count 

316426  (1  incomplete) 

364525  (1  incomplete) 

Table  4.  Text  files  of  repeated  known  strings 


An  open  source  application,  Visual  Binary  Diff  [12],  was  used  to  compare 
the  two  images  created.  Visual  Binary  Diff  or  VBinDiff  opens  the  two  files 
simultaneously  and  dumps  their  hex  and  ASCII  outputs  one  on  top  of  the  other. 


8  Captures  of  greater  than  1,600  MB’s  have  been  achieved. 
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Differences  between  the  two  file  are  marked  red.  Figure  3  and  4  are  screenshots 
of  the  VBinDiff  showing  how  the  information  is  presented. 


rai  C:\Windows\systerr32\cmd 


.exe  -  VBinDiff.exe  '2  files\contro!2files"  "2  files\test" 


Figure  3.  VBinDiff  output  -  Not  difference  in  data 


C:\Windows\system32\cmd.exe  -  VBinD~ff.exe  '2  files\control2files"  "2  filesYtest" 
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Figure  4.  VBinDiff  -  Difference  in  data  marked  in  red 


A  trial  version  of  a  Text/  Flex  editor,  010  Editor  [11]  was  used  to  inspect 
the  image  files  to  locate  traces  of  the  known  strings.  The  editor  is  capable  of 
display  the  hex  and  ASCII  representation  beside  each  other,  and  has  powerful 
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features  such  as  searching  for  ASCII,  EBCDIC,  Unicode  strings.  Figure  5  is  a 
screenshot  of  the  010  Editor  and  it  shows  how  the  information  is  represented. 


Figure  5.  VBinDiff-  Difference  in  data  marked  in  red 


C.  TESTING  RESULTS 

Three  sets  of  images  were  collected  and  analyzed.  A  summary  of  the 
images  collected  is  found  in  Table  5.  The  transfer  block  size  defined  by  the 
TX_BLOCK_SIZE  constant  in  the  file  public. h  (See  Appendix  E)  is  the  equivalent 
of  the  block  size  parameter  of  the  GNU  dd  tool  [43],  The  MemReader  driver  and 
application  needs  to  be  rebuilt  if  the  TX_BLOCK_SIZE  is  changed. 
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Set  1 

Set  2 

Set  3 

Control  Image  File 
Size 

2,086,424KB 
(-2037. 5MB) 

2,086,424KB 

2,086,424KB 

Test  Image  File  Size 

1,638,464KB 

1,263,936KB 

587,904KB 

Transfer  Block  Size 

4096bytes 

4096bytes 

4096bytes 

Table  5.  Test  Results 


The  control  image  file  size  created  was  the  same  for  the  all  three 
collections.  MDD,  however,  did  not  manage  to  extract  information  from  certain 
regions  of  memory.  The  MDD  output  shows  that  there  are  8  failed  mappings 
during  the  creation  of  the  control  image.  See  Figure  6.  These  failed  mapping 
would  not  have  resulted  in  a  smaller  image  as  MDD  will  pad  the  images  at 
locations  where  the  mapping  failed.  This  is  important  as  the  MemReader 
application  should  behave  in  the  same  way  so  that  it  can  be  compared  against 
the  images  created  by  MDD. 


Figure  6.  MDD  output  screen  when  creating  control  image 


43 


D. 


ANALYSIS  OF  RESULTS 


1.  Preliminary  Analysis 


The  first  significant  observation  was  that  even  with  the  MDD,  a  complete 
image  of  RAM  could  not  be  extracted.  The  blocks  that  MDD  was  unable  to 
extract  could  possibly  be  the  regions  which  the  MemReader  driver  gets  a 
STATUS  CONFLICTING  ADDRESSES  error. 


A  comparison  was  done  between  the  control  images  collected.  Upon 
visual  inspection  using  VBinDiff,  the  memory  segment  from  0x00000000  to 
OxOOOFFFF,  the  first  megabyte,  remained  largely  the  same.  This  is  expected  as 
most  of  the  system  information  would  have  been  the  first  to  be  loaded  into  the 
RAM  and  this  information  should  remain  largely  the  same.  This  was  consistent 
with  the  comparison  between  the  test  images.  Significant  differences  began  only 
at  the  one  megabyte  offset.  Figure  7  shows  the  VBinDiff  differences  between 
two  control  images.  Figure  8  shows  the  VBinDiff  differences  between  two  test 
images. 


Figure  7.  VBinDiff  -  Difference  in  data  between  Set1\control  and  Set2\control 
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C:\Windows\system32\cmd.exe  WBD\VBinDiff.exe  Set2\test  SetlXtest 
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Figure  8.  VBinDiff  —  Difference  in  data  between  Set1\test  and  Set2\test 


2.  Testing  for  the  Presence  of  Data 

The  image  files  were  searched  using  parts  of  the  known  string  as  a 
“signature”  and  it  was  expected  that  the  repeated  known  strings  occupied 
multiple  fragments  of  contiguous  chunk  of  memory.  The  “signature”  used  to 
detect  the  TestFile1.txt  and  TestFile2.txt  strings  are  “usually’  and  “quick  brown" 
respectively.  Figure  10  to  13  shows  the  result  of  a  “find”  on  the  two  signatures  in 
the  control  and  test  images.  The  box  highlighted  in  yellow  is  a  graphical 
representation  of  the  image  file.  Regions  marked  in  blue  are  the  locations  where 
the  signatures  are  found.  In  an  ideal  situation,  the  content  of  the  TestFiles 
should  occupy  a  contiguous  block  of  memory.  The  fragmentation  into  smaller 
chunks  by  the  Operating  System’s  Memory  Management  is  to  fulfill  existing  and 
new  memory  requests  at  the  time  the  image  was  created. 
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Figure  9.  A  find  on  the  signature  “usually”  for  set  1  control  image 


Figure  10.  A  find  on  the  signature  “usually”  for  set  1  test  image 
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Figure  11.  A  find  on  the  signature  “quick  brown”  for  set  1  control  image 


Figure  12.  A  find  on  the  signature  “quick  brown”  for  set  1  test  image 
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Both  the  signatures  are  littered  throughout  the  entire  length  of  the  control 
image.  These  are  the  blue  segments  as  on  Figure  10  and  Figure  12.  Since  the 
test  image  captured  is  incomplete  (approximately  440MB  less),  an  approximation 
of  it  would  be  the  first  1600  MB  of  the  control  image.  The  Memory  Management 
Unit  of  the  Operating  System  would  have  made  some  changes  to  memory  in 
between  the  time  the  two  images  are  captured,  but  the  general  spread  pattern 
should  still  be  observable.  The  vertical  yellow  line  in  Figure  12  marks  the  end  of 
the  capture  test  image.  The  top  half  of  the  boxed  region  would  be  an 
approximate  of  the  captured  test  image.  Compare  this  to  the  boxed  region  in 
Figure  13.  The  blue  regions  are  more  spread  out,  imagine  stretching  the  box 
region  in  Figure  12,  but  the  similarity  between  the  two  is  apparent.  This  is 
observable  from  Figure  10  and  1 1  as  well. 

3.  Testing  by  Comparison 

The  VBinDiff  tool  was  used  to  compare  the  control  and  test  image  of  each 
set.  Figure  13  show  that  the  images  in  set  1  are  largely  the  same  at  the 
beginning  of  the  images.  The  first  difference  between  the  two  images  is  at  the 
offset  position  0x00123060  as  seen  in  Figure  14.  The  two  images  remain  largely 
the  same  with  slight  difference,  like  those  in  Figure  14,  until  the  offset  position 
0x0014C000.  These  changes  can  be  due  to  the  memory  requirement  needed  by 
the  MemReader  application  and  driver.  From  position  0x00140000  onwards,  the 
two  images  start  to  differ.  Figure  15  shows  the  image  at  position  0x00140000. 
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Figure  13.  Set  1 :  No  difference  between  the  images  (till  0x00123050) 


Figure  14.  Set  1:  First  difference  between  the  images  (0x00123060) 
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Figure  15.  Set  1 :  Position  (0x0014C000)  where  images  start  to  differ 

The  result  is  consistent  with  the  images  extracted  in  set  2,  see  Figure  16  - 
18,  and  set  3,  see  Figure  19-21.  The  only  notable  difference  is  that  point  which 
the  data  on  the  two  images  start  to  get  drastically  different.  In  both  set  2  and  set 
3,  the  tripping  point  is  at  0x001 5F000  -  76KB  later  than  set  1 . 
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Figure  16.  Set  2:  No  difference  between  the  images  (till  0x001 1A000) 
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Figure  17.  Set  2:  First  difference  between  the  images  (0x001 1A000) 


Figure  18.  Set  2:  Position  (0x001 5F000)  where  images  start  to  differ 


51 


C2J  Command  Prompt  -  ..\VSDWBinDiff.exe  Set3\control  Set3\te;t 

ISet3\control 


0000 

0000: 

FC 

A4 

00 

F0 

FC 

A4 

00 

F0 

C3 

E2 

00 

F0 

FC 

A4 

00 

F0 

"n .="n  .= 

|T.E"n.E 

0000 

0010: 

FC 

A4 

00 

F0 

54 

FF 

00 

F0 

CE 

A3 

00 

F0 

FC 

A4 

00 

F0 

*’n  .ET  .E 

Jpi-  =  "n  .= 

0000 

0020: 

A5 

FE 

00 

F0 

87 

E9 

00 

F0 

FC 

A4 

00 

F0 

FC 

A4 

00 

F0 

Nl .EpB  .= 

"n.E"n.E 

0000 

0030: 

FC 

A4 

00 

F0 

59 

6A 

00 

F0 

57 

EF 

00 

F0 

FC 

A4 

00 

F0 

"n.EVj.E 

Un.E«n.E 

0000 

0040: 

14 

00 

00 

C0 

4D 

F8 

00 

F0 

41 

F8 

00 

F0 

A7 

5C 

00 

F0 

. . .  41°  .E 

A°.Ea\.E 

0000 

0050: 

39 

E7 

00 

F0 

59 

F8 

00 

F0 

2E 

E8 

00 

F0 

D2 

EF 

00 

F0 

9-t.EV°.E 

.5 . =nfl -= 

0000 

0060: 

2C 

58 

00 

F0 

6C 

57 

00 

F0 

6E 

FE 

00 

F0 

53 

FF 

00 

F0 

,X.=1W.= 

nl.ES  .= 

0000 

0070: 

53 

FF 

00 

F0 

A4 

F0 

00 

F0 

C7 

EF 

00 

F0 

50 

6C 

00 

C0 

S  „=n=  -  = 

Ilfl.EPl.  L 

0000 

0080: 

FC 

A4 

00 

F0 

FC 

A4 

00 

F0 

FC 

A4 

00 

F0 

FC 

A4 

00 

F0 

"n .="n  .= 

»n.E"n.E 

Set3\test 

0000 

0000: 

FC 

A4 

00 

F0 

FC 

A4 

00 

F0 

C3 

E2 

00 

F0 

FC 

A4 

00 

F0 

>'n.E"n.E 

rr  .E"n.E 

0000 

0010: 

FC 

A4 

00 

F0 

54 

FF 

00 

F0 

CE 

A3 

00 

F0 

FC 

A4 

00 

F0 

"ii  .ET  .E 

{Jd.="n.= 

0000 

0020: 

A5 

FE 

00 

F0 

87 

E9 

00 

F0 

FC 

A4 

00 

F0 

FC 

A4 

00 

F0 

Nl .  =p0  .= 

"n.E"n.E 

0030: 

FC 

A4 

00 

F0 

59 

6A 

00 

F0 

57 

EF 

00 

F0 

FC 

A4 

00 

F0 

"n.EVj.E 

Wn . E™n .  E 

0000 

0040: 

14 

00 

00 

C0 

4D 

F8 

00 

F0 

41 

F8 

00 

F0 

A7 

SC 

00 

F0 

A°.=2\.E 

0000 

0050: 

39 

E7 

00 

F0 

59 

F8 

00 

F0 

2E 

E8 

00 

F0 

D2 

EF 

00 

F0 

9t.EV°.E 

.5 . =nfl  -  = 

0000 

0060: 

2C 

58 

00 

F0 

6C 

57 

00 

F0 

6E 

FE 

00 

F0 

53 

FF 

00 

F0 

,X.E1W.E 

nl.ES  -E 

0000 

0070: 

53 

FF 

00 

F0 

A4 

F0 

00 

F0 

C7 

EF 

00 

F0 

50 

6C 

00 

C0 

S  ,=n=  .= 

Ilfl.EPl.  L 

0000 

0080: 

FC 

A4 

00 

F0 

FC 

A4 

00 

F0 

FC 

A4 

00 

F0 

FC 

A4 

00 

F0 

''n.E"n.E 

"n.E«n.E 

Arrow  keys  move 
C  ;MH  I  i/EBCDIC 


F  find  RET  next  difference 

E  edit  file  G  goto  position 


ESC  quit 
Q  quit 


ALT  freeze  top 
CTRL  freeze  botton 


Figure  19.  Set  3:  No  difference  between  the  images  (till  0x00123090) 


Figure  20.  Set  3:  First  difference  between  images  (0x00123090) 
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rai  Command  Prompt  -  ..\VBD\VBinDiff.exe  Set3\control  Set3\te;t 
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Figure  21 .  Set  3:  Position  (0x001 5F000)  where  images  start  to  differ 


Bringing  the  discussion  back  to  the  images  in  set  1 ,  the  rest  of  the  images 
from  position  0x0014C000  onwards  are  patches  where  data  is  different  -  see 
Figure  22,  and  patches  where  data  match  -  see  Figure  23.  This  is  expected,  as 
the  Operating  System  would  have  changed  some  of  the  data  in  RAM  -  the 
patches  where  data  is  different,  but  not  all  of  the  data  in  RAM  -  thereby  leaving 
some  areas  where  data  still  do  match.  One  of  the  areas  where  data  do  match 
contains  the  information  that  was  deliberately  inserted  into  memory.  Figure  24 
shows  the  earliest  location,  0x005CA012,  where  either  of  the  “known  strings”  is 
found.  This  is  a  match,  albeit  expected,  to  the  first  address  in  the  red  boxes  of 
Figure  9  and  10.  Upon  closer  inspection  of  the  two  red  boxes  in  Figure  9  and  10 
and  Figure  24,  both  010  Editor  and  VBindiff  reveal  that  the  “known  strings”  are 
occupying  the  same  addresses  in  the  two  images 
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Command  Prompt-  ..\VBD\VBinDiff.exe  SetlAcontrol  Setl\te:t 


ISetlNcontro  1 

001F  14C0 : 

00  00 

001F  14D0: 

001F  14E0 : 

00  00 

, 

001F  14F0 : 

00 

00 

001F  1500: 

00  00 

001F  1510: 

001F  1520: 

00 

00 

00 

001F  1530: 

00  00 

001F  1540: 

00 

00 

BetlNtest 

001F  14C0 : 

00  00 

001F  14D0 : 

001F  14E0 : 

00  00 

001F  14F0 : 

00 

00 

001F  1500: 

00  00 

001F  1510: 

001F  1520: 

00 

00 

00 

_  m 

001F  1530: 

00  00 

001F  1540: 

00 

00 

Arrow  keys  move 

F 

f  ind 

RET  next 

dif  f  erence 

ESC  quit 

ALT 

freeze  top 

C  VMM •  I/EBCDIC 

E 

edit  file 

G  goto 

position 

Q  quit 

CTRL 

freeze  bottom 

Figure  22.  Set  1 :  An  area  (0x001  F14C0)  where  data  do  not  match 


Figure  23.  Set  1 :  An  area  (0x001  FFD20)  where  the  data  match 
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Figure  24.  Set  1 :  The  first  instance  of  the  signature  “usually” 


Figure  25  show  the  VBinDiff  output  of  the  earliest  instance  of  the  signature 
“quick  brown".  Not  only  does  the  segment  of  memory  match  in  both  images,  this 
is  consistent  with  the  results  boxed  in  red  of  Figure  1 1  and  Figure  12. 


■  ..\VBDWBinDiff.exe  Setl\control  Setl\test 


I  |Setl\control  I 

lum  r. 
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00 
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00 
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r .  .t.h. 
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e  .  d .  .  o  . 

001E 

6068:  76 

00 

65 

00 

72 

00 

20 

00 

74 

00 

68 

00 

65 

00 

20 

00 

v.e.r.  . 

t .  b .  e  .  . 

001E 

6078:  6C 

00 

61 
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64 

00 

6F 

00 

67 

00 
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20 

00 

74 

00 

68 

00 

65 

00 

20 

00 

71 

00 

75 

00 
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74 

00 
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00 

6C 

00 
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00 
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00 
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00 
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00 
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67 

00 
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00 

74 
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00 

65 
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00 
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001E 

6038:  71 

00 

75 

00 

69 

00 

63 

00 

6B 

00 

20 

00 
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00 

72 

00 
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77 
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00 
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00 

78 

00 
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00 
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00 

75 
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00 

70 
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00 
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Figure  25. 


Set  1 :  The  first  instance  of  the  signature  “quick  brown” 
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Figure  26  and  Figure  27  shows  the  pattern  of  matching  and  unmatching 
segments  of  memory  continue  further  in  the  images  of  set  1.  This  pattern 
continues  to  the  end  of  the  images. 


Figure  26.  Set  1 :  Another  area  (OxOFFFCOOO)  where  data  do  not  match 


Figure  27.  Set  1 :  Another  area  (OxOFFFAODO)  where  the  data  match 
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VII.  FUTURE  WORK 


The  goal  of  this  research  is  an  attempt  to  show  the  possibility  of  creating 
an  image  of  volatile  RAM  using  only  user  mode  privileges,  and  the  help  of  a 
custom  preinstalled  windows  driver.  It  is  far  from  being  a  completed  and  finished 
product  and  below  are  some  possibilities  of  how  this  is  research  can  be  further 
polished  and  perpetuated. 

A.  STABILITY  OF  THE  MEMREADER  DRIVER 

As  mentioned  in  previous  chapters,  the  MemReader  driver  should  not  be 
considered  a  production  quality  product.  The  source  of  crashes  needs  to  be 
determined.  This  will  require  “live”  debugging  to  be  done  and  likely  a  detailed 
understanding  of  memory  management  of  the  Windows  kernel.  Once  the 
stability  issue  is  addresses,  the  driver  can  used  as  a  commercially  viable 
package. 

B.  POWER  MANAGEMENT  EVENT  CALLBACKS 

There  are  two  power  callback  events  currently  registered  in  the 
MemReader  driver,  the  DeviceSelfManagedloStart  and  the 
DeviceSelfManagedloSuspend  events.  These  are  shell  functions  without 
implementation.  Implementing  these  functions  would  complete  the  driver  and 
make  the  environment  where  it  operates  be  more  stable,  especially  when  there  is 
a  power  transition  event  when  it  is  operating. 

C.  TESTING  ON  DIFFERENT  FLAVORS  OF  WINDOWS  VISTA 

There  are  four  flavors  to  the  Windows  Vista  Operating  System,  the  Home, 
Home  Premium,  Business  and  Ultimate  and  there  is  a  64-bit  version  that  takes 
advantage  of  the  64-bit  processors.  Since  the  development  was  done  on  a 
System  running  Windows  Vista  Business,  testing  was  not  done  on  the  other 
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flavors  and  versions  of  Windows  Vista.  The  driver  was  also  not  tested  on  any 
other  hardware  architecture  except  for  the  x86  architecture  (the  development 
environment). 

D.  WRITE  CAPABILITY  (SIMILAR  TO  DD) 

Since  the  physical  memory  segment  is  fully  accessible  by  the  Memreader 
device  driver,  its  functionality  can  be  expanded  to  include  write  capabilities  much 
like  what  the  UNIX  command  dd  can  do.  Currently  the  physical  memory  section 
is  opened  and  mapped  with  a  READ_ONLY  attribute,  this  needs  to  be  changed 
to  include  the  possibility  of  writing  to  it.  The  write  command  can  be  implemented 
in  many  ways.  This  can  include  registering  another  callback  for  I/O  control 
events  or  simply  by  modifying  the  memaddr  data  structure  to  include  addition 
parameters  needed  to  initiate  the  write  operation. 

The  read  and  write  capability  can  be  further  extended  to  files  and  even 
blocks  and  sectors  of  the  hard  disk,  much  like  dd.  Adding  a  write  capability  can 
result  in  obvious  negative  effects  for  forensic  purposes. 
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VIII.  CONCLUSIONS  AND  RECOMMENDATIONS 


The  main  objective  of  this  research  is  to  show  that,  with  a  suitable  device 
driver,  it  is  possible  for  a  user  mode  process  to  create  an  image  of  RAM.  In 
order  to  verify  that  the  MemReader  driver  and  application  pair  is  functioning 
correctly,  it  must  be  shown  that  the  image  created  using  the  MemReader  driver 
and  application  is  correct. 

It  is  impossible  to  determine  the  exact  content  of  RAM  when  the 
MemReader  driver  and  application  was  creating  the  image.  In  fact,  the  very 
operation  of  the  MemReader  driver  and  application  will  alter  the  content  of 
memory.  Therefore,  it  is  only  possible  to  verify  to  a  certain  degree  that  the 
information  captured  is  correct  and  accurate.  For  the  driver  to  work  seamlessly, 
an  in-depth  knowledge  of  Windows  Vista  is  needed.  The  proprietary  nature  of 
Windows  operating  system  makes  this  a  tricky  task  as  many  hypotheses  are 
formed  and  testing  is  needed.  It  is  however  not  unfathomable  that  such  a  driver 
can  be  written. 

The  results  clearly  shows  that  the  image  created  by  the  MemReader 
driver  and  the  user  mode  MemReader  application  has  capture  the  consistent  part 
of  RAM,  which  mainly  consist  of  machine  and  system  related  information.  The 
image  created  by  MemReader  also  captured  the  injected  known  strings  at 
position  where  they  are  expected.  There  is  strong  evidence  that  the  driver  and 
application  pair  in  able  to  create  an  image  of  RAM. 

The  results  achieved  are  satisfactory  and  they  clearly  show  that  it  is 
possible  to  create  an  image  of  RAM  using  a  user-mode  application  with  the  help 
of  a  suitable,  pre-installed  device  driver.  The  objectives  of  the  research  are 
therefore  met. 
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APPENDIX  A:  INSTRUCTIONS  TO  SETTING  UP  A  SIGNING 

ENVIRONMENT 


Test  Signing  [35] 

1 .  Prepare  a  computer  for  signing 

a.  Install  WDK 

2.  Create  a  test  certificate  and  adding  it  to  the  Trusted  Root  certificate  store 
and  the  Trusted  Publishers  certificate  store 

a.  Makecert  -r  -pe  -ss  SubjectCertStoreName  -n  “ CN=CertName ” 
OutputFile.  cer 

b.  certmgr.exe  -add  OutputFile. cer  -s  -r  localMachine  root 

c.  certmgr.exe  -add  OutputFile. cer  -s  -r  localMachine  trustedpublisher 

3.  Create  a  catalog  file  using  lnf2Cat9 

a.  Create  a  driver  package  directory  that  contains  all  of  the  files  in 
your  driver  package. 

b.  Create  an  INF  file  in  the  driver  package  directory  and  edit  it  for 
Windows  Vista.  Change  the  build  date  and  the  version  number  to  6. 
For  example:  DriverVer=  12/04/2008,  6. 0.1.0 

c.  Inf2cat.exe  /driver:C:\WinDDK\6000\src\kmdf\memreader\ 

/os:Vista_x86 

Test-sign  the  catalog  file  using  SignTool 

SignTool  sign  /v  /ac  CrossCertificateFile  Is  SPCCertificateStore  / n 
SPCSubjectName  It  http://timestamp.verisiqn.com/scripts/timestamp.dll  Good. cat 


9  Registration  is  required  at  the  Winqual  website  before  the  lnf2Cat  application  is  available 
for  download. 
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APPENDIX  B:  INSTRUCTIONS  TO  SETUP  A  KERNEL 
DEVELOPMENT  ENVIRONMENT 


1 .  Download  and  install  the  Windows  Driver  Kit  (WDK) 

a.  WDK  is  available  for  download  the  Microsoft  Connect  website, 
http://connect.microsoft.com/.  Registration  is  required  before  the  WDK 
is  available  for  download. 

b.  Upon  logging  into  Microsoft  connect,  browse  to  the  connections 
directory  and  join  the  Windows  Driver  Kit  (WDK),  Windows  Logo  Kit 
(WLK)  and  Windows  Driver  Framework  (WDF)10. 

c.  The  WDK  installation  package  can  be  downloaded  from  the  Windows 
Driver  Kit  (WDK),  Windows  Logo  Kit  (WLK)  and  Windows  Driver 
Framework  (WDF)  connection  page. 

d.  Run  the  downloaded  executable  and  install  WDK. 

2.  Download  and  install  DebugView 

a.  DebugView  is  freely  available  for  download  from  the  Microsoft 

Technet,  http://technet.microsoft.com/en- 

us/svsinternals/bb896647.aspx. 

b.  Run  the  downloaded  executable  to  install  DebugView. 

c.  DebugView  requires  elevated  privileges  to  function.  Right  click  on  the 
application  shortcut  and  select  the  ‘Run  as  administrator’  option  to  run 
DebugView. 


10  If  this  connection  is  not  available  for  joining,  a  request  can  be  made  to  the  administrator 
through  the  connection  directory  help. 
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APPENDIX  C:  INSTRUCTIONS  FOR  INSTALLING  AND 
UNINSTALLING  WINDOWS  DRIVER 


INSTALLATION  (x86  Free  Build  Environment) 

1.  Build  the  driver  files 

2.  Copy  the  WDF  Co-installer  files  (WdfColnstaller<vers/on#>.dll)  from  the 
<l/l/DKF?007">\redist\wdf\x86  directory  to  directory  where  the  build  output  files 
(INF,  .sys,  .pdb,  .mac  and  .obj  files)  are  found. 

3.  Open  Control  Panel  >  Add  Hardware  menu  (Administrator  Privileged  needed) 

4.  At  the  Add  Hardware  wizard  select  “Next  >” 

5.  Select  the  “Install  the  hardware  that  I  manually  select  from  a  list  (Advance)” 
radio  button  then  hit  “Next  >” 

6.  Select  “Show  All  Devices”  and  hit  “Next  >” 

7.  Select  “Have  Disk...” 

8.  In  the  “Install  From  Disk”  menu  select  “Browse...” 

9.  In  the  “Locate  File”  menu,  navigate  to  the  directory  where  the  outputs  files  are 
located  and  select  the  installation  (INF)  file  then  select  “Open” 

10.  Select  “OK”  and  hit  “Next  >” 

1 1  .Hit  “Next  >”  again 

12.  If  a  “Windows  Security”  alert  pops  up,  Select  the  option  “Install  this  driver 
software  anyway” 

13.  Select  “Finish”  to  complete  the  installation 


UNINSTALLATION 

1.  Open  Control  Panel  >  System  >  Device  Manager  menu  (Administrator 
Privileged  needed) 
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2.  Locate  and  select  the  device  node  in  the  “Device  Manager”  Menu 

3.  Right  click  on  the  selected  device  node  and  select  “Uninstall” 

4.  In  the  “Confirm  Device  Uninstall”  menu  check  the  “Delete  the  driver  software 
for  this  device”  checkbox  and  hit  “OK” 
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APPENDIX  D:  INSTRUCTIONS  FOR  CREATING  A  RAM  IMAGE 


1 .  Start  the  system  and  log  into  the  user  account 

2.  Open  a  text  file  with  a  repeated  (file  size  ~150MB)  known  string  (e.g.  a  quick 
brown  fox  jumped  over  the  lazy  dog). 

Creating  a  RAM  image  using  ManTech’s  DD 

3.  Open  a  Command  Prompt  with  administrator  privileges 

a.  Click  on  the  start  Windows  Key  and  select  Programs  >  Accessories  > 
Command  Prompt 

b.  Right  click  of  the  highlighted  Command  Prompt  and  select  “Run  as 
administrator” 

4.  Navigate  to  the  directory  where  the  ManTech’s  DD  tool  is  installed 

c.  cd  C:\MDD 

5.  Create  an  image  file  of  the  RAM 

d .  m  d  d_v  1.3.  exe  -o  control,  bin 

Creating  a  RAM  image  using  MemReader 

3.  Open  a  Command  Prompt 

a.  Click  on  the  start  Windows  Key  and  select  Programs  >  Accessories 
>  Command  Prompt  and  click  on/  select  it 

4.  Navigate  to  the  directory  where  the  MemReader  application  is  installed 

a.  cd  C:\MemReader 

5.  Create  an  image  file  of  the  RAM 

a.  MemReader.exe  test.bin  <offset> 
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APPENDIX  E:  FULL  SOURCE  CODE  AND  INSTALLATION  FILES 


The  source  code  of  MemReader  is  licensed  under  the  BSD  license. 

public. h 

/* 

*  Copyright  (c)  2008,  Vincent  Cheong 

*  All  rights  reserved. 

* 

*  Redistribution  and  use  in  source  and  binary  forms,  with  or  without 

*  modification,  are  permitted  provided  that  the  following  conditions 
are  met: 

*  *  Redistributions  of  source  code  must  retain  the  above  copyright 

*  notice,  this  list  of  conditions  and  the  following  disclaimer. 

*  *  Redistributions  in  binary  form  must  reproduce  the  above 
copyright 

*  notice,  this  list  of  conditions  and  the  following  disclaimer  in 
the 

*  documentation  and/or  other  materials  provided  with  the 
distribution . 

*  *  Neither  the  name  of  the  Naval  Postgraduate  School  nor  the 

*  names  of  its  contributors  may  be  used  to  endorse  or  promote 
products 

*  derived  from  this  software  without  specific  prior  written 

permission . 

* 

*  THIS  SOFTWARE  IS  PROVIDED  BY  VINCENT  CHEONG  ''AS  IS''  AND  ANY 

*  EXPRESS  OR  IMPLIED  WARRANTIES,  INCLUDING,  BUT  NOT  LIMITED  TO,  THE 
IMPLIED 

*  WARRANTIES  OF  MERCHANTABILITY  AND  FITNESS  FOR  A  PARTICULAR  PURPOSE 
ARE 

*  DISCLAIMED.  IN  NO  EVENT  SHALL  <copyright  holder>  BE  LIABLE  FOR  ANY 

*  DIRECT,  INDIRECT,  INCIDENTAL,  SPECIAL,  EXEMPLARY,  OR  CONSEQUENTIAL 
DAMAGES 

*  (INCLUDING,  BUT  NOT  LIMITED  TO,  PROCUREMENT  OF  SUBSTITUTE  GOODS  OR 
SERVICES; 

*  LOSS  OF  USE,  DATA,  OR  PROFITS;  OR  BUSINESS  INTERRUPTION)  HOWEVER 
CAUSED  AND 

*  ON  ANY  THEORY  OF  LIABILITY,  WHETHER  IN  CONTRACT,  STRICT  LIABILITY,  OR 
TORT 

*  (INCLUDING  NEGLIGENCE  OR  OTHERWISE)  ARISING  IN  ANY  WAY  OUT  OF  THE  USE 
OF  THIS 

*  SOFTWARE,  EVEN  IF  ADVISED  OF  THE  POSSIBILITY  OF  SUCH  DAMAGE. 

*/ 

#define  WHILE (a)  \ 

while (  pragma (warning (disable : 4 127 )  )  a 
pragma (warning (disable:4127)  )  ) 

#def ine  TX  BLOCK  SIZE  4096 
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//  Define  an  Interface  Guid  so  that  app  can  find  the  device  and  talk  to 
it . 

DEF INE_GU ID  (GUI D_DEVINTERFACE_ECHO , 

0xcdc35b6e,  0xbe4,  0x4936,  Oxbf,  0x5f,  0x55,  0x37,  0x38,  Oxa,  0x7c, 
0x1  a)  ; 

//  { CDC35B6E-0BE4-4  936-BF5F-5537  380A7C1A} 
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driver.h 


/* 

*  Copyright  (c)  2008,  Vincent  Cheong 

*  All  rights  reserved. 

* 

*  Redistribution  and  use  in  source  and  binary  forms,  with  or  without 

*  modification,  are  permitted  provided  that  the  following  conditions 
are  met : 

*  *  Redistributions  of  source  code  must  retain  the  above  copyright 

*  notice,  this  list  of  conditions  and  the  following  disclaimer. 

*  *  Redistributions  in  binary  form  must  reproduce  the  above 
copyright 

*  notice,  this  list  of  conditions  and  the  following  disclaimer  in 
the 

*  documentation  and/or  other  materials  provided  with  the 
distribution . 

*  *  Neither  the  name  of  the  Naval  Postgraduate  School  nor  the 

*  names  of  its  contributors  may  be  used  to  endorse  or  promote 
products 

*  derived  from  this  software  without  specific  prior  written 
permission . 

* 

*  THIS  SOFTWARE  IS  PROVIDED  BY  VINCENT  CHEONG  ''AS  IS''  AND  ANY 

*  EXPRESS  OR  IMPLIED  WARRANTIES,  INCLUDING,  BUT  NOT  LIMITED  TO,  THE 
IMPLIED 

*  WARRANTIES  OF  MERCHANTABILITY  AND  FITNESS  FOR  A  PARTICULAR  PURPOSE 
ARE 

*  DISCLAIMED.  IN  NO  EVENT  SHALL  Ccopyright  holder>  BE  LIABLE  FOR  ANY 

*  DIRECT,  INDIRECT,  INCIDENTAL,  SPECIAL,  EXEMPLARY,  OR  CONSEQUENTIAL 
DAMAGES 

*  (INCLUDING,  BUT  NOT  LIMITED  TO,  PROCUREMENT  OF  SUBSTITUTE  GOODS  OR 
SERVICES; 

*  LOSS  OF  USE,  DATA,  OR  PROFITS;  OR  BUSINESS  INTERRUPTION)  HOWEVER 
CAUSED  AND 

*  ON  ANY  THEORY  OF  LIABILITY,  WHETHER  IN  CONTRACT,  STRICT  LIABILITY,  OR 
TORT 

*  (INCLUDING  NEGLIGENCE  OR  OTHERWISE)  ARISING  IN  ANY  WAY  OUT  OF  THE  USE 
OF  THIS 

*  SOFTWARE,  EVEN  IF  ADVISED  OF  THE  POSSIBILITY  OF  SUCH  DAMAGE. 

*/ 

#def ine  INITGUID 

#include  <ntddk.h> 

#include  <wdf.h> 

#include  "device. h" 

#include  "queue. h" 

//  WDFDRIVER  Events 
DRIVER_INITIALIZE  DriverEntry; 

NTSTATUS 

MemReaderEvtDeviceAdd ( 
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IN  WDFDRIVER  Driver, 

IN  PWDFDEVICE^INIT  Devicelnit 

)  ; 

NTSTATUS 

MemReaderPrintDriverVersion ( 

)  ; 
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driver.c 


/* 

*  Copyright  (c)  2008,  Vincent  Cheong 

*  All  rights  reserved. 

* 

*  Redistribution  and  use  in  source  and  binary  forms,  with  or  without 

*  modification,  are  permitted  provided  that  the  following  conditions 
are  met : 

*  *  Redistributions  of  source  code  must  retain  the  above  copyright 

*  notice,  this  list  of  conditions  and  the  following  disclaimer. 

*  *  Redistributions  in  binary  form  must  reproduce  the  above 
copyright 

*  notice,  this  list  of  conditions  and  the  following  disclaimer  in 
the 

*  documentation  and/or  other  materials  provided  with  the 
distribution . 

*  *  Neither  the  name  of  the  Naval  Postgraduate  School  nor  the 

*  names  of  its  contributors  may  be  used  to  endorse  or  promote 
products 

*  derived  from  this  software  without  specific  prior  written 
permission . 

* 

*  THIS  SOFTWARE  IS  PROVIDED  BY  VINCENT  CHEONG  ''AS  IS''  AND  ANY 

*  EXPRESS  OR  IMPLIED  WARRANTIES,  INCLUDING,  BUT  NOT  LIMITED  TO,  THE 
IMPLIED 

*  WARRANTIES  OF  MERCHANTABILITY  AND  FITNESS  FOR  A  PARTICULAR  PURPOSE 
ARE 

*  DISCLAIMED.  IN  NO  EVENT  SHALL  Ccopyright  holder>  BE  LIABLE  FOR  ANY 

*  DIRECT,  INDIRECT,  INCIDENTAL,  SPECIAL,  EXEMPLARY,  OR  CONSEQUENTIAL 
DAMAGES 

*  (INCLUDING,  BUT  NOT  LIMITED  TO,  PROCUREMENT  OF  SUBSTITUTE  GOODS  OR 
SERVICES; 

*  LOSS  OF  USE,  DATA,  OR  PROFITS;  OR  BUSINESS  INTERRUPTION)  HOWEVER 
CAUSED  AND 

*  ON  ANY  THEORY  OF  LIABILITY,  WHETHER  IN  CONTRACT,  STRICT  LIABILITY,  OR 
TORT 

*  (INCLUDING  NEGLIGENCE  OR  OTHERWISE)  ARISING  IN  ANY  WAY  OUT  OF  THE  USE 
OF  THIS 

*  SOFTWARE,  EVEN  IF  ADVISED  OF  THE  POSSIBILITY  OF  SUCH  DAMAGE. 

*/ 

#include  "driver. h" 

#if def  ALLOC^PRAGMA 

#pragma  alloc  text  (INIT,  DriverEntry) 

#pragma  alloc  text  (INIT,  MemReaderPrintDriverVersion) 

#pragma  alloc  text  (PAGE,  MemReaderEvtDeviceAdd) 

#endif 


NTSTATUS 
DriverEntry ( 

IN  PDRIVER_OBJECT  DriverOb j ect , 
IN  PUNICODE_STRING  RegistryPath 
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{ 


NTSTATUS  status; 

WDF_DRIVER_CONFIG  config; 

WDF_DRIVER_CONFIG_INIT (Sconfig, 

MemReaderEvtDeviceAdd 

)  ; 


status  =  Wdf DriverCreate (DriverObj ect, 

RegistryPath, 

WDF_NO_OB JECT_ATTRIBUTES , 

Sconf ig, 

WDF_NO_HANDLE) ; 
if  ( !NT_SUCCESS (status) )  { 

DbgPrint ( "MEM:  Error:  Wdf DriverCreate  failed  Ox%x\n", 

status) ; 

return  status; 

} 

#if  DBG 

EchoPrintDriverVersion ( )  ; 

#endif 

return  status; 

} 

NTSTATUS 

MemReaderEvtDeviceAdd ( 

IN  WDFDRIVER  Driver, 

IN  PWDFDEVICE^INIT  Devicelnit 

) 

{ 

NTSTATUS  status; 

UNREFERENCED^PARAMETER (Driver) ; 

PAGED_CODE ( ) ; 

DbgPrint ( "MEM :  Enter  EchoEvtDeviceAdd\n" ) ; 
status  =  MemReaderDeviceCreate (Devicelnit) ; 
return  status; 

} 

NTSTATUS 

MemReaderPrintDriverVersion ( 

) 

{ 

NTSTATUS 
WDFSTRING 
UNICODE_STRING 

WDF  DRIVER  VERSION  AVAILABLE  PARAMS  ver; 


status ; 
string; 
us; 
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//  Retreive  version  string  and  print  that  in  the  debugger, 
status  =  WdfStringCreate  (NULL,  WDF_NO_OBJECT_ATTRIBUTES ,  Sstring)  ; 
if  ( !NT_SUCCESS (status)  )  { 

DbgPrint ( "Error :  WdfStringCreate  failed  Ox%x\n",  status); 
return  status; 

} 


status  =  Wdf DriverRetrieveVersionString (WdfGetDriver ( ) ,  string); 
if  ( !NT_SUCCESS (status) )  { 

// 

//No  need  to  worry  about  delete  the  string  object  because 
//  by  default  it's  parented  to  the  driver  and  it  will  be 
//  deleted  when  the  driverobject  is  deleted  when  the 
DriverEntry 

//  returns  a  failure  status. 

// 

DbgPrint ( "Error :  Wdf DriverRetrieveVersionString  failed  Ox%x\n", 

status) ; 

return  status; 

} 


Wdf StringGetUnicodeString ( string,  Sus)  ; 

DbgPrint ( "MEM:  MemReader  %wZ,  built  on  %s  %s\n",  Sus, 
_ DATE _ ,  _ TIME _ )  ; 

WdfOb j ectDelete (string)  ; 

string  =  NULL;  //  To  avoid  referencing  a  deleted  object. 


//  Find  out  to  which  version  of  framework  this  driver  is  bound 
WDF_DRIVER_VERSION_AVAILABLE_PARAMS_INIT ( Sver,  1,  0); 

if  (WdfDriverlsVersionAvailable (WdfGetDriver () ,  Sver)  ==  TRUE) 
DbgPrint ( "MEM:  Yes,  framework  version  is  1.0\n"); 

}else  { 


} 


DbgPrint ( "MEM:  No,  framework  verison  is  not  1.0\n"); 


to . 
{ 


return  STATUS_SUCCESS ; 

} 
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device. h 


/* 

*  Copyright  (c)  2008,  Vincent  Cheong 

*  All  rights  reserved. 

* 

*  Redistribution  and  use  in  source  and  binary  forms,  with  or  without 

*  modification,  are  permitted  provided  that  the  following  conditions 
are  met : 

*  *  Redistributions  of  source  code  must  retain  the  above  copyright 

*  notice,  this  list  of  conditions  and  the  following  disclaimer. 

*  *  Redistributions  in  binary  form  must  reproduce  the  above 
copyright 

*  notice,  this  list  of  conditions  and  the  following  disclaimer  in 
the 

*  documentation  and/or  other  materials  provided  with  the 
distribution . 

*  *  Neither  the  name  of  the  Naval  Postgraduate  School  nor  the 

*  names  of  its  contributors  may  be  used  to  endorse  or  promote 
products 

*  derived  from  this  software  without  specific  prior  written 
permission . 

* 

*  THIS  SOFTWARE  IS  PROVIDED  BY  VINCENT  CHEONG  ''AS  IS''  AND  ANY 

*  EXPRESS  OR  IMPLIED  WARRANTIES,  INCLUDING,  BUT  NOT  LIMITED  TO,  THE 
IMPLIED 

*  WARRANTIES  OF  MERCHANTABILITY  AND  FITNESS  FOR  A  PARTICULAR  PURPOSE 
ARE 

*  DISCLAIMED.  IN  NO  EVENT  SHALL  Ccopyright  holder>  BE  LIABLE  FOR  ANY 

*  DIRECT,  INDIRECT,  INCIDENTAL,  SPECIAL,  EXEMPLARY,  OR  CONSEQUENTIAL 
DAMAGES 

*  (INCLUDING,  BUT  NOT  LIMITED  TO,  PROCUREMENT  OF  SUBSTITUTE  GOODS  OR 
SERVICES; 

*  LOSS  OF  USE,  DATA,  OR  PROFITS;  OR  BUSINESS  INTERRUPTION)  HOWEVER 
CAUSED  AND 

*  ON  ANY  THEORY  OF  LIABILITY,  WHETHER  IN  CONTRACT,  STRICT  LIABILITY,  OR 
TORT 

*  (INCLUDING  NEGLIGENCE  OR  OTHERWISE)  ARISING  IN  ANY  WAY  OUT  OF  THE  USE 
OF  THIS 

*  SOFTWARE,  EVEN  IF  ADVISED  OF  THE  POSSIBILITY  OF  SUCH  DAMAGE. 

*/ 

#include  " . . \exe\public . h" 

//  The  device  context  performs  the  same  job  as 
//  a  WDM  device  extension  in  the  driver  frameworks 
typedef  struct  _DEVICE_CONTEXT 
{ 

ULONG  PrivateDeviceData;  //  just  a  placeholder 
}  DEVICE_CONTEXT ,  * PDEVICE^CONTEXT ; 

//  This  macro  will  generate  an  inline  function  called 
WdfOb j ectGet _DEVICE_CONTEXT 

//  which  will  be  used  to  get  a  pointer  to  the  device  context  memory 
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//  in  a  type  safe  manner. 

WDF_DECLARE_CONTEXT_TYPE ( DEVICE^CONTEXT ) 

//  Function  to  initialize  the  device  and  its  callbacks 

NTSTATUS 

MemReaderDeviceCreate ( 

PWDFDEVICE_INIT  Devicelnit 

)  ; 

//  Device  events 

VOID 

MemReaderEvtDeviceContextCleanup ( 

IN  WDFDEVICE  hDevice 

)  ; 

NTSTATUS 

MemReaderEvtDeviceSelfManagedloStart ( 

IN  WDFDEVICE  Device 

)  ; 

NTSTATUS 

MemReaderEvt Devi ceSelfManagedlo Suspend ( 

IN  WDFDEVICE  Device 

)  ; 
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device. c 


/* 

*  Copyright  (c)  2008,  Vincent  Cheong 

*  All  rights  reserved. 

* 

*  Redistribution  and  use  in  source  and  binary  forms,  with  or  without 

*  modification,  are  permitted  provided  that  the  following  conditions 
are  met : 

*  *  Redistributions  of  source  code  must  retain  the  above  copyright 

*  notice,  this  list  of  conditions  and  the  following  disclaimer. 

*  *  Redistributions  in  binary  form  must  reproduce  the  above 
copyright 

*  notice,  this  list  of  conditions  and  the  following  disclaimer  in 
the 

*  documentation  and/or  other  materials  provided  with  the 
distribution . 

*  *  Neither  the  name  of  the  Naval  Postgraduate  School  nor  the 

*  names  of  its  contributors  may  be  used  to  endorse  or  promote 
products 

*  derived  from  this  software  without  specific  prior  written 
permission . 

* 

*  THIS  SOFTWARE  IS  PROVIDED  BY  VINCENT  CHEONG  ''AS  IS''  AND  ANY 

*  EXPRESS  OR  IMPLIED  WARRANTIES,  INCLUDING,  BUT  NOT  LIMITED  TO,  THE 
IMPLIED 

*  WARRANTIES  OF  MERCHANTABILITY  AND  FITNESS  FOR  A  PARTICULAR  PURPOSE 
ARE 

*  DISCLAIMED.  IN  NO  EVENT  SHALL  Ccopyright  holder>  BE  LIABLE  FOR  ANY 

*  DIRECT,  INDIRECT,  INCIDENTAL,  SPECIAL,  EXEMPLARY,  OR  CONSEQUENTIAL 
DAMAGES 

*  (INCLUDING,  BUT  NOT  LIMITED  TO,  PROCUREMENT  OF  SUBSTITUTE  GOODS  OR 
SERVICES; 

*  LOSS  OF  USE,  DATA,  OR  PROFITS;  OR  BUSINESS  INTERRUPTION)  HOWEVER 
CAUSED  AND 

*  ON  ANY  THEORY  OF  LIABILITY,  WHETHER  IN  CONTRACT,  STRICT  LIABILITY,  OR 
TORT 

*  (INCLUDING  NEGLIGENCE  OR  OTHERWISE)  ARISING  IN  ANY  WAY  OUT  OF  THE  USE 
OF  THIS 

*  SOFTWARE,  EVEN  IF  ADVISED  OF  THE  POSSIBILITY  OF  SUCH  DAMAGE. 

*/ 

#include  "driver. h" 

#if def  ALLOC^PRAGMA 

#pragma  alloc  text  (PAGE,  MemReaderDeviceCreate) 

#pragma  alloc  text  (PAGE,  MemReaderEvtDeviceSelfManagedloStart) 

#pragma  alloc  text  (PAGE,  MemReaderEvtDeviceSelfManagedloSuspend) 

#endif 


NTSTATUS 

MemReaderDeviceCreate ( 

PWDFDEVICE_INIT  Devicelnit 

) 
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{ 

WDF_OBJECT_ATTRIBUTES  deviceAttributes ; 

PDEVICE_CONTEXT  deviceContext; 

WDF_PNPPOWER_EVENT_CALLBACKS  pnpPowerCallbacks; 

WDFDEVICE  device; 

NTSTATUS  status; 

PAGED_CODE ( ) ; 

WDF_PNPPOWER_EVENT_CALLBACKS_INIT ( &pnpPowerCallbacks ) ; 

//  Register  pnp/power  callbacks  so  that  we  can  start  and  stop  the 
timer  as  the  device 

//  gets  started  and  stopped. 

pnpPowerCallbacks . EvtDeviceSelfManagedloInit  = 
MemReaderEvtDeviceSelfManagedloStart ; 

pnpPowerCallbacks . EvtDeviceSelfManagedloSuspend  = 

MemReaderEvt Device Self Managedlo Suspend; 

pnpPowerCallbacks . EvtDeviceSelfManagedloRestart  = 
MemReaderEvtDeviceSelfManagedloStart ; 

//  Register  the  PnP  and  power  callbacks. 

Wdf Devi cel nit Set PnpPowerEventCallbacks (Devi cel nit, 
SpnpPowerCallbacks ) ; 

WDF_OBJECT_ATTRIBUTES_INIT_CONTEXT_TYPE ( SdeviceAttributes , 
DEVICE_CONTEXT) ; 

//  Set  WDFDEVICE  synchronization  scope.  By  opting  for  device 

level 

//  synchronization  scope,  all  the  queue  and  timer  callbacks  are 
//  synchronized  with  the  device-level  spinlock. 
deviceAttributes . SynchronizationScope  = 

Wdf SynchronizationScopeDevice; 

status  =  Wdf DeviceCreate ( SDevicelnit,  SdeviceAttributes ,  Sdevice) ; 

if  (NT_SUCCESS (status) )  { 

//  Get  the  device  context  and  initialize  it. 
WdfObjectGetJDEVICE_CONTEXT  is  an 

//  inline  function  generated  by  WDF  DECLARE  CONTEXT  TYPE  macro 

in  the 

//  device. h  header  file.  This  function  will  do  the  type 
checking  and  return 

//  the  device  context.  If  you  pass  a  wrong  object  handle 
//  it  will  return  NULL  and  assert  if  run  under  framework 
verifier  mode. 

deviceContext  =  WdfObjectGet  DEVICE  CONTEXT (device) ; 
deviceContext->PrivateDeviceData  =  0; 

//  Create  a  device  interface  so  that  application  can  find  and 

talk 

//  to  us . 

status  =  Wdf DeviceCreateDevicelnterf ace ( 
device. 
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&GUID_DEVINTERFACE_ECHO, 
NULL  / /  Referencestring 
)  ; 


if  (NT_SUCCESS (status) )  { 

//  Initialize  the  I/O  Package  and  any  Queues 
status  =  MemReaderQueuelnitialize (device)  ; 

} 

} 

return  status; 

} 


NTSTATUS 

MemReaderEvtDeviceSelfManagedloStart ( 
IN  WDFDEVICE  Device 


{ 

DbgPrint ( "MEM:  MemReaderEvtDeviceSelfManagedIoInit\n" )  ; 
PAGED_CODE ( ) ; 

Wdf IoQueueStart (Wdf DeviceGetDef aultQueue (Device) ) ; 

DbgPrint (  "MEM:  MemReaderEvtDeviceSelfManagedIoInit\n" )  ; 
return  STATUS_SUCCESS ; 

} 

NTSTATUS 

MemReaderEvt Devi ceSelfManagedlo Suspend ( 

IN  WDFDEVICE  Device 

) 

{ 

PAGED_CODE ( ) ; 

DbgPrint ( "MEM:  MemReaderEvtDeviceSelfManagedIoSuspend\n" ) ; 
Wdf IoQueueStopSynchronously (Wdf DeviceGetDef aultQueue (Device) ) 
DbgPrint (  "MEM:  MemReaderEvtDeviceSelfManagedIoSuspend\n" ) ; 
return  STATUS_SUCCESS ; 

} 
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queue. h 

/* 

*  Copyright  (c)  2008,  Vincent  Cheong 

*  All  rights  reserved. 

* 

*  Redistribution  and  use  in  source  and  binary  forms,  with  or  without 

*  modification,  are  permitted  provided  that  the  following  conditions 
are  met : 

*  *  Redistributions  of  source  code  must  retain  the  above  copyright 

*  notice,  this  list  of  conditions  and  the  following  disclaimer. 

*  *  Redistributions  in  binary  form  must  reproduce  the  above 
copyright 

*  notice,  this  list  of  conditions  and  the  following  disclaimer  in 
the 

*  documentation  and/or  other  materials  provided  with  the 
distribution . 

*  *  Neither  the  name  of  the  Naval  Postgraduate  School  nor  the 

*  names  of  its  contributors  may  be  used  to  endorse  or  promote 
products 

*  derived  from  this  software  without  specific  prior  written 
permission . 

* 

*  THIS  SOFTWARE  IS  PROVIDED  BY  VINCENT  CHEONG  ''AS  IS''  AND  ANY 

*  EXPRESS  OR  IMPLIED  WARRANTIES,  INCLUDING,  BUT  NOT  LIMITED  TO,  THE 
IMPLIED 

*  WARRANTIES  OF  MERCHANTABILITY  AND  FITNESS  FOR  A  PARTICULAR  PURPOSE 
ARE 

*  DISCLAIMED.  IN  NO  EVENT  SHALL  Ccopyright  holder>  BE  LIABLE  FOR  ANY 

*  DIRECT,  INDIRECT,  INCIDENTAL,  SPECIAL,  EXEMPLARY,  OR  CONSEQUENTIAL 
DAMAGES 

*  (INCLUDING,  BUT  NOT  LIMITED  TO,  PROCUREMENT  OF  SUBSTITUTE  GOODS  OR 
SERVICES; 

*  LOSS  OF  USE,  DATA,  OR  PROFITS;  OR  BUSINESS  INTERRUPTION)  HOWEVER 
CAUSED  AND 

*  ON  ANY  THEORY  OF  LIABILITY,  WHETHER  IN  CONTRACT,  STRICT  LIABILITY,  OR 
TORT 

*  (INCLUDING  NEGLIGENCE  OR  OTHERWISE)  ARISING  IN  ANY  WAY  OUT  OF  THE  USE 
OF  THIS 

*  SOFTWARE,  EVEN  IF  ADVISED  OF  THE  POSSIBILITY  OF  SUCH  DAMAGE. 

*/ 

//  Memory  Address  data  structure  that  is  also  defined  in  memreaderapp 
typedef  struct  _memaddr{ 

ULONGLONG  offset; 

ULONGLONG  len; 

}  memaddr; 

//  This  is  the  context  that  can  be  placed  per  queue 
//  and  would  contain  per  queue  information, 
typedef  struct  _QUEUE_CONTEXT  { 

HANDLE  hPhysicalMemory  ; 

PVOID  pVirtualAddr  ; 

memaddr  ma  ; 
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WDFREQUEST  CurrentRequest ; 


}  QUEUE^CONTEXT,  * PQUEUE_CONTEXT ; 

WDF_DECLARE_CONTEXT_TYPE_WITH_NAME (QUEUE^CONTEXT,  QueueGetContext ) 

NTSTATUS 

MemReaderQueuelnitialize ( 

WDFDEVICE  hDevice 

)  ; 

VOID 

MemReaderEvtloQueueContextDestroy ( 

WDFOBJECT  Object 

)  ; 

//  Callback  Events  from  the  IoQueue  object 

VOID 

MemReaderEvtRequestCancel ( 

IN  WDFREQUEST  Request 

)  ; 

VOID 

MemReaderEvtloRead ( 

IN  WDFQUEUE  Queue, 

IN  WDFREQUEST  Request, 

IN  size  t  Length 

)  ; 

VOID 

MemReaderEvtloWrite ( 

IN  WDFQUEUE  Queue, 

IN  WDFREQUEST  Request, 

IN  size  t  Length 

)  ; 
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queue. c 


/* 

*  Copyright  (c)  2008,  Vincent  Cheong 

*  All  rights  reserved. 

* 

*  Redistribution  and  use  in  source  and  binary  forms,  with  or  without 

*  modification,  are  permitted  provided  that  the  following  conditions 
are  met : 

*  *  Redistributions  of  source  code  must  retain  the  above  copyright 

*  notice,  this  list  of  conditions  and  the  following  disclaimer. 

*  *  Redistributions  in  binary  form  must  reproduce  the  above 
copyright 

*  notice,  this  list  of  conditions  and  the  following  disclaimer  in 
the 

*  documentation  and/or  other  materials  provided  with  the 
distribution . 

*  *  Neither  the  name  of  the  Naval  Postgraduate  School  nor  the 

*  names  of  its  contributors  may  be  used  to  endorse  or  promote 
products 

*  derived  from  this  software  without  specific  prior  written 
permission . 

* 

*  THIS  SOFTWARE  IS  PROVIDED  BY  VINCENT  CHEONG  ''AS  IS''  AND  ANY 

*  EXPRESS  OR  IMPLIED  WARRANTIES,  INCLUDING,  BUT  NOT  LIMITED  TO,  THE 
IMPLIED 

*  WARRANTIES  OF  MERCHANTABILITY  AND  FITNESS  FOR  A  PARTICULAR  PURPOSE 
ARE 

*  DISCLAIMED.  IN  NO  EVENT  SHALL  Ccopyright  holder>  BE  LIABLE  FOR  ANY 

*  DIRECT,  INDIRECT,  INCIDENTAL,  SPECIAL,  EXEMPLARY,  OR  CONSEQUENTIAL 
DAMAGES 

*  (INCLUDING,  BUT  NOT  LIMITED  TO,  PROCUREMENT  OF  SUBSTITUTE  GOODS  OR 
SERVICES; 

*  LOSS  OF  USE,  DATA,  OR  PROFITS;  OR  BUSINESS  INTERRUPTION)  HOWEVER 
CAUSED  AND 

*  ON  ANY  THEORY  OF  LIABILITY,  WHETHER  IN  CONTRACT,  STRICT  LIABILITY,  OR 
TORT 

*  (INCLUDING  NEGLIGENCE  OR  OTHERWISE)  ARISING  IN  ANY  WAY  OUT  OF  THE  USE 
OF  THIS 

*  SOFTWARE,  EVEN  IF  ADVISED  OF  THE  POSSIBILITY  OF  SUCH  DAMAGE. 

*/ 

#include  "driver. h" 

#if def  ALLOC^PRAGMA 

#pragma  alloc  text  (PAGE,  MemReaderQueuelnitialize) 

#endif 

NTSTATUS 

MemReaderQueuelnitialize ( 

WDFDEVICE  Device 

) 

{ 

WDFQUEUE 
NTSTATUS 
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queue; 
status ; 


UNICODE_STRING 

PQUEUE_CONTEXT 

OBJECT_ATTRIBUTES 

WDF_IO_QUEUE_CONFIG 

WDF_OBJECT_ATTRIBUTES 

PAGED_CODE ( ) ; 

DbgPrint ( "MEM:  Queue 


usPhysicalMemory; 

queueContext; 

oa; 

queueConf ig; 
queueAttributes ; 

Initialize  X!\n"); 


//  Configure  a  default  queue  so  that  requests  that  are  not 

//  conf igure-f owarded  using  Wdf DeviceConf igureRequestDispatching  to 

goto 

//  other  queues  get  dispatched  here. 
WDF_IO_QUEUE_CONFIG_INIT_DEFAULT_QUEUE ( 

SqueueConf ig, 

Wdf IoQueueDispatchSequential 

)  ; 


//  register  event  callbacks 
queueConf ig . EvtloRead  =  MemReaderEvtloRead; 
queueConf ig . EvtloWrite  =  MemReaderEvtloWrite; 

//  Fill  in  a  callback  for  destroy,  and  our  QUEUE  CONTEXT  size 
WDF_OBJECT_ATTRIBUTES_INIT_CONTEXT_TYPE ( SqueueAttributes , 
QUEUE_CONTEXT ) ; 

queueAttributes . EvtDestroyCallback  = 
MemReaderEvtloQueueContextDestroy; 

status  =  Wdf IoQueueCreate ( 

Device, 

SqueueConf ig, 

SqueueAttributes , 

&queue 

)  ; 


if (  !NT_SUCCESS (status)  )  { 

DbgPrint ( "Wdf IoQueueCreate  failed  Ox%x\n" , status ) ; 
return  status; 


//  Get  our  Driver  Context  memory  from  the  returned  Queue  handle 
queueContext  =  QueueGetContext (queue)  ; 

//initialise  queue  context 
queueContext->CurrentRequest  =  NULL; 
queueContext->ma . len  =  0; 

queueContext->ma . of f set  =  0; 

queueContext->hPhysicalMemory  =  NULL; 
queueContext->pVirtualAddr  =  NULL; 

//Initializes  a  counted  Unicode  string 
RtllnitUnicodeString (  SusPhysicalMemory, 

L" \\ Device \\Phy si calMemory" ) ; 
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//The  InitializeObj ectAttributes  macro  initializes  the  opaque 
OBJECT_ATTRIBUTES 

//structure,  which  specifies  the  properties  of  an  object  handle 
to  routines  that 

//open  handles. 

//The  OBJECT  ATTRIBUTES  structure  specifies  attributes  that  can 
be  applied  to 

//objects  or  object  handles  by  routines  that  create  objects 
and/or  return  handles 
//to  objects. 

InitializeObjectAttributes (  &oa,  SusPhysicalMemory, 

OBJ_CASE_INSENSITIVE 

OB J_KERNEL_HANDLE , 

(HANDLE)  NULL, 

( PSECURITY_DESCRI PTOR) 

NULL)  ; 


//The  ZwOpenSection  routine  opens  a  handle  for  an  existing 
section  object. 

//An  object  that  represents  a  section  of  memory  that  can  be 

shared 

status  =  ZwOpenSection (  & (queueContext->hPhysicalMemory) , 
SECTION_ALL_ACCESS,  Soa  ); 

if  (  !NT_SUCCESS (status)  ) 

{ 

DbgPrint ( "MEM:  Failed  to  open  %wZ !  Status  %p\n", 
usPhysicalMemory,  status)  ; 

queueContext->hPhysicalMemory  =  NULL; 
return  status; 

} 

DbgPrint ( "MEM:  Opened  section  handle  %p  in  driver\n", 
queueContext->hPhysicalMemory) ; 

return  status; 

} 

VOID 

MemReaderEvtloQueueContextDestroy ( 

WDFOBJECT  Object 


{ 

DbgPrint ( "MEM:  IoContextQueueDestroy ! \n" ) ; 
return ; 

} 


VOID 

MemReaderEvtRequestCancel ( 

IN  WDFREQUEST  Request 

) 

{ 

PQUEUE_CONTEXT  queueContext  = 
QueueGetContext (WdfRequestGetloQueue (Request) ) ; 
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DbgPrint ( "MEM:  MemReaderRequestCancel  called  on  Request  Ox%p\n", 
Request) ; 

WdfRequestCompleteWithlnf ormation (Request,  STATUS  CANCELLED,  OL)  ; 

//  This  book  keeping  is  synchronized  by  the  common 
//  Queue  presentation  lock 

ASSERT (queueContext->CurrentRequest  ==  Request); 
queueContext->CurrentRequest  =  NULL; 

return; 

} 


VOID 

MemReaderEvtloRead ( 

IN  WDFQUEUE  Queue, 

IN  WDFREQUEST  Request, 
IN  size^t  Length 

) 


NTSTATUS 

WDFMEMORY 

LARGE^INTEGER 

PQUEUE_CONTEXT 

ULONG 


Status ; 
memory; 

sectionOf f set  ; 

queueContext 

writeBlockSize 


QueueGetContext (Queue) ; 
TX  BLOCK  SIZE; 


DbgPrint ( "MEM:  EchoEvtloRead  Called!  Queue  Ox%p,  Request  Ox%p 
Length  %d,  writeBlockSize  %d,  \ 

Offset 

%d\n" , Queue, Request, Length, writeBlockSize, queueContext->ma  .offset)  ; 


/ /  Read  what  we  have 
if (  Length  <=  0  )  { 

WdfRequestCompleteWithlnf ormation (Request,  STATUS  SUCCESS, 
(ULONG_PTR) OL) ; 

return; 

} 


if (  writeBlockSize  >  (ULONG) (queueContext->ma . len  -  queueContext- 
>ma . offset)  ) { 

writeBlockSize  =  (ULONG) (queueContext->ma . len  - 
queueContext->ma . of f set)  ; 

} 

DbgPrint ( "MEM:  After  decrement  ma . len=%u\n" ,  queueContext- 
>ma .len) ; 

sectionOf f set . QuadPart  =  queueContext->ma . of f set; 

Status  =  ZwMapViewOf Section (  queueContext->hPhysicalMemory,  // 
handle  to  section  object 

ZwCurrentProcess ( ) ,  //  macro  to  retrieve  handle  for  current 

process 

& (queueContext->pVirtualAddr) , 

OL,  //  ZeroBits 

Length,  //  CommitSize 

SsectionOf f set,  //  Section  Offset 
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SLength,  //  View  Size 
ViewShare,  //  Inherit  Disposition 

0, 

PAGE_READONLY  //  Win32  Protection 

)  ; 

//increase  offset  even  if  mapping  fails 
queueContext->ma . of f set  +=  writeBlockSize; 

if (  !NT_SUCCESS (Status) )  { 

DbgPrint ( "MEM:  EvtloRead  Mapping  of  Section  Object  failed 
Status:  0x%x\n" , Status) ; 

DbgPrint ( "MEM:  EvtloRead  Mapping  of  Section  Object  failed 
ma.offset=%u  ma . len=%u\n" , 

(queueContext->ma . of f set) ,  queueContext->ma . len) ; 
WdfVerif ierDbgBreakPoint ( )  ; 

WdfRequestCompleteWithlnf ormation (Request,  Status,  0L)  ; 
return; 

} 

//  Get  the  request  memory 

Status  =  WdfRequestRetrieveOutputMemory (Request,  Smemory) ; 
if (  !NT_SUCCESS (Status)  )  { 

DbgPrint ( "MEM:  EvtloRead  Could  not  get  request  memory 
buffer  0x%x\n" , Status ) ; 

WdfVerif ierDbgBreakPoint ( )  ; 

WdfRequestCompleteWithlnf ormation (Request,  Status,  0L)  ; 
return; 

} 

/ /  Copy  the  memory  out 

DbgPrint ( "MEM:  Copy  %d  bytes  from  buffer !\n".  Length); 

Status  =  WdfMemoryCopyFromBuf fer (  memory,  //  destination 

0,  //  offset  into  the  destination 

memory 

queueContext->pVirtualAddr , / / 

queueContext->Buf fer 

(Length)  ) ; 

if (  !NT_SUCCESS (Status)  )  { 

DbgPrint ( "MEM:  EvtloRead:  WdfMemoryCopyFromBuf fer  failed 
0x%x\n",  Status); 

WdfRequestComplete (Request,  Status) ; 
return; 

} 


if (queueContext->pVirtualAddr) { 

DbgPrint ( "MEM:  EvtloRead  Unmapping  Section  Object!\n"); 
Status  =  ZwUnmapViewOf Section ( 

ZwCurrentProcess  ( ) ,  //  macro  to  retrieve  handle  for 

current  process 

queueContext->pVirtualAddr )  ; 

queueContext->pVirtualAddr  =  NULL; 

if (  !NT_SUCCESS (Status) )  { 

DbgPrint ( "MEM:  EvtloRead  Unmapping  of  Section  Object 
failed:  0x%x\n" , Status); 


87 


OL)  ; 


WdfVerif ierDbgBreakPoint ( ) ; 

WdfRequestCompleteWithlnf ormation (Request,  Status, 
return; 


//  Set  transfer  information 

WdfRequestSetlnf ormation (Request,  (ULONG  PTR) (Length)); 

//  Mark  the  request  is  cancelable 

WdfRequestMarkCancelable (Request,  MemReaderEvtRequestCancel ) ; 
WdfRequestComplete (Request,  Status) ; 

DbgPrint ( "MEM:  Completed  EvtloRead  View  Size=%d ! \n"  ,  Length)  ; 
return; 

} 


VOID 

MemReaderEvtloWrite ( 

IN  WDFQUEUE  Queue, 

IN  WDFREQUEST  Request, 
IN  size  t  Length 

) 


NTSTATUS 

WDFMEMORY 

PQUEUE_CONTEXT 

PVOID 

Length,  ' saml ' )  ; 


Status ; 
memory; 

queueContext  =  QueueGetContext (Queue) ; 
temp  =  ExAllocatePoolWithTag (NonPagedPool , 


DbgPrint ("MEM: 

%d\n". 


EvtloWrite  Called!  Queue  Ox%p, 
Queue, Request, Length) ; 


Request  Ox%p  Length 


//  Get  the  memory  buffer 

Status  =  WdfRequestRetrievelnputMemory (Request,  Smemory) ; 
if (  !NT_SUCCESS (Status)  )  { 

DbgPrint ( "MEM:  EvtloWrite  Could  not  get  request  memory 
buffer  Ox%x\n", 

Status) ; 

WdfVerif ierDbgBreakPoint ( ) ; 

WdfRequestComplete (Request,  Status) ; 
return; 

} 


/ /  Copy  the  memory  in 

Status  =  WdfMemoryCopyToBuf fer (  memory, 

0,  //  offset  into  the  source  memory 

temp. 

Length  ) ; 

if (  !NT_SUCCESS (Status)  )  { 

DbgPrint ( "MEM:  EchoEvtloWrite  WdfMemoryCopyToBuf fer  failed 
0x%x\n",  Status); 
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WdfVerif ierDbgBreakPoint ( )  ; 
WdfRequestComplete (Request,  Status) ; 
return; 


queueContext->ma . len  =  ( (memaddr  * ) temp) ->len; 
queueContext->ma . of f set  =  ((memaddr  *) temp) ->off set; 
DbgPrint ( "MEM:  ma.len  %u  ma. offset  %u ! \n" , queueContext- 
>ma . len, queueContext->ma . offset) ; 

//  Set  transfer  information 
WdfRequestSetlnf ormation (Request,  (ULONG  PTR) Length) ; 
DbgPrint ( "MEM:  Write  After  Set  Inf ormation ! \n" ) ; 

//  Specify  the  request  is  cancelable 

WdfRequestMarkCancelable (Request,  MemReaderEvtRequestCancel ) 
DbgPrint ( "MEM:  Write  After  RequestMarkCancellable ! \n" ) ; 

queueContext->CurrentRequest  =  Request; 

WdfRequestComplete (Request,  Status) ; 

DbgPrint ( "MEM:  return !\n"); 

return; 

} 


89 


memreaderapp.cpp 

/* 

*  Copyright  (c)  2008,  Vincent  Cheong 

*  All  rights  reserved. 

* 

*  Redistribution  and  use  in  source  and  binary  forms,  with  or  without 

*  modification,  are  permitted  provided  that  the  following  conditions 
are  met : 

*  *  Redistributions  of  source  code  must  retain  the  above  copyright 

*  notice,  this  list  of  conditions  and  the  following  disclaimer. 

*  *  Redistributions  in  binary  form  must  reproduce  the  above 
copyright 

*  notice,  this  list  of  conditions  and  the  following  disclaimer  in 
the 

*  documentation  and/or  other  materials  provided  with  the 
distribution . 

*  *  Neither  the  name  of  the  Naval  Postgraduate  School  nor  the 

*  names  of  its  contributors  may  be  used  to  endorse  or  promote 
products 

*  derived  from  this  software  without  specific  prior  written 
permission . 

* 

*  THIS  SOFTWARE  IS  PROVIDED  BY  VINCENT  CHEONG  ''AS  IS''  AND  ANY 

*  EXPRESS  OR  IMPLIED  WARRANTIES,  INCLUDING,  BUT  NOT  LIMITED  TO,  THE 
IMPLIED 

*  WARRANTIES  OF  MERCHANTABILITY  AND  FITNESS  FOR  A  PARTICULAR  PURPOSE 
ARE 

*  DISCLAIMED.  IN  NO  EVENT  SHALL  Ccopyright  holder>  BE  LIABLE  FOR  ANY 

*  DIRECT,  INDIRECT,  INCIDENTAL,  SPECIAL,  EXEMPLARY,  OR  CONSEQUENTIAL 
DAMAGES 

*  (INCLUDING,  BUT  NOT  LIMITED  TO,  PROCUREMENT  OF  SUBSTITUTE  GOODS  OR 
SERVICES; 

*  LOSS  OF  USE,  DATA,  OR  PROFITS;  OR  BUSINESS  INTERRUPTION)  HOWEVER 
CAUSED  AND 

*  ON  ANY  THEORY  OF  LIABILITY,  WHETHER  IN  CONTRACT,  STRICT  LIABILITY,  OR 
TORT 

*  (INCLUDING  NEGLIGENCE  OR  OTHERWISE)  ARISING  IN  ANY  WAY  OUT  OF  THE  USE 
OF  THIS 

*  SOFTWARE,  EVEN  IF  ADVISED  OF  THE  POSSIBILITY  OF  SUCH  DAMAGE. 

*/ 

#def ine  INITGUID 

#include  <windows.h> 

#include  <strsafe.h> 

#include  <setupapi.h> 

#include  <stdio.h> 

#include  <stdlib.h> 

#include  "public. h" 

#def ine  NUM_ASYNCH_IO  100 

#def ine  VISTA_VERSION_NUMBER  6 
#def ine  XP  VERSION  NUMBER 
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#def ine  ACCEPTABLE_VERSION  XP_VERSION_NUMBER 

#def ine  READER_TYPE  1 

#def ine  WRITER_TYPE  2 

typedef  struct  _memaddr{ 

ULONGLONG  offset; 

ULONGLONG  len; 

}  memaddr; 


PCHAR  DevicePath; 
memaddr  ma; 

PCHAR 

GetDevicePath ( 

IN  LPGUID  InterfaceGuid 

)  ; 

BOOLEAN 

correctOsVersion ( )  ; 

ULONGLONG 
CheckDiskSpace ( 

IN  HANDLE  hDumpFile 

)  ; 

BOOLEAN 
WriteMemAddr ( 

IN  HANDLE  hDevice 

)  ; 

BOOLEAN 
ReadRam ( 

IN  HANDLE  hDevice, 

IN  HANDLE  hDumpFile, 

IN  ULONG  blockSize 

)  ; 


void  _ cdecl 

main  ( 

in  int  argc, 

_ in^ecount (argc)  char*  argv [ ] 

) 

{ 

HANDLE  hDevice  =  INVALID_HANDLE_VALUE, 

hDumpFile  =  INVALID_HANDLE_VALUE ; 

HANDLE  thl  =  NULL; 

ULONGLONG  testLength  =  0; 

BOOLEAN  result; 

ULONG  offset  =  0  ; 

if (  argc  ==  2  )  { 

} 

else  if  (  argc  ==  3  )  { 

offset  =  atol (argv [2 ] )  *  1024  *  1024;  //  in  MB 
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} 

else  { 

printf ( "Wrong  Usage:  >  memreader  <f ilename>\n" ) ; 

printf ( "Wrong  Usage:  or  >  memreader  <filename>  <offset  in 
MB>  <end>\n") ; 

goto  exit; 

} 

printf ( "Dumping  to  file  %s\n",  argv[l]); 

printf ( "Enter  ' q '  to  exit  and  any  key  to  continue:  "); 

int  ip  =  getchar(); 

if (  (ip  ==  ' q ' )  | |  (ip  ==  ' Q ' )  ) { 

goto  exit; 

} 

else  { 

} 

ma. offset  =  offset; 
ma.len  =  0; 

if (  ! correctOsVersion ( )  ) 

goto  exit  ; 


WCHAR  dumpFile [MAX_PATH]  =  {  L'\0'  }; 

//  just  do  a  simple  file  name  check  and  we  are  good  to  go? 
hDumpFile  =  CreateFile (  argv[l],  GENERIC_WRITE,  0,  NULL, 
CREATE_ALWAY S ,  0,  NULL  ); 

if (  hDumpFile  ==  INVALID_HANDLE_VALUE  )  { 

fprintf (  stderr,  "  ->  ERROR:  Failed  to  open  dump  file 
\"%s\"!  (%u)\n\n",  dumpFile,  GetLastError  ()) ; 

printf ("  ->  ERROR:  Failed  to  open  dump  file  \"%s\"! 
(%u)\n\n",  dumpFile,  GetLastError ()) ; 
goto  exit; 

} 

testLength  =  CheckDiskSpace (hDumpFile) ; 

DevicePath  =  GetDevicePath ( (LPGUID) &GUID_DEVINTERFACE_ECHO) ; 

printf ( "DevicePath :  %s\n",  DevicePath); 

hDevice  =  CreateFile (DevicePath, 

GENERIC_READ | GENERIC_WRITE, 

F I LE_S  HARE_RE AD , 

NULL, 

0PEN_EXI STING, 

0, 

NULL  )  ; 

if  (hDevice  ==  INVALID_HANDLE_VALUE)  { 

printf ( "Failed  to  open  device.  Error  %d\n"  ,  GetLastError ()); 


92 


goto  exit; 

} 

printf ( "Opened  device  successfully\n" ) ; 
WriteMemAddr (hDevice)  ; 

Sleep (100) ; 

ReadRam (hDevice,  hDumpFile,  TX  BLOCK  SIZE); 


exit : 

if  (thl  ! =  NULL)  { 

WaitForSingleOb j ect  (thl,  INFINITE) ; 
CloseHandle (thl) ; 

} 

if  (hDevice  !=  INVAL I D_HANDLE_VALUE )  { 

CloseHandle (hDevice) ; 

} 

printf ( "Exiting . . . \n"  )  ; 
return; 


} 

PUCHAR 

CreatePatternBuf fer ( 

IN  ULONG  Length 

) 

{ 

unsigned  int  i; 

PUCHAR  p,  pBuf ; 

pBuf  =  (PUCHAR) malloc (Length) ; 
if  (  pBuf  ==  NULL  )  { 

printf  ( "Could  not  allocate  %d  byte  bufferin'' ,  Length) 
return  NULL; 

} 

p  =  pBuf; 


for(i=0;  i  <  Length;  i++  )  { 

*p  =  (UCHAR)i; 

P++; 

} 

return  pBuf; 

} 

BOOLEAN 

Verif yPatternBuf fer ( 

IN  PUCHAR  pBuffer, 

IN  ULONG  Length 


unsigned  int  i; 
PUCHAR  p  =  pBuffer; 
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for (  i=0;  i  <  Length;  i++  )  { 


if (  *p  ! =  (UCHAR) (i  &  OxFF)  )  { 

printf ( "Pattern  changed.  SB  Ox%x,  Is  Ox%x\n", 
(UCHAR)  (i  &  OxFF)  ,  *p)  ; 

return  FALSE; 

} 

P++; 

} 

return  TRUE; 


PCHAR 

GetDevicePath ( 

IN  LPGUID  InterfaceGuid 


HDEVINFO  HardwareDevicelnfo; 

SP_DEVICE_INTERFACE_DATA  Devicelnterf aceData; 

PSP_DEVICE_INTERFACE_DETAIL_DATA  Devicelnterf aceDetailData  =  NULL 
ULONG  Length,  RequiredLength  =  0; 

BOOL  bResult; 


HardwareDevicelnfo  =  SetupDiGetClassDevs ( 

InterfaceGuid, 

NULL, 

NULL, 

(DIGCF_PRESENT  |  D I GCF_DEVICE INTERFACE) ) 

if  (HardwareDevicelnfo  ==  INVALID_HANDLE_VALUE)  { 
printf ( "SetupDiGetClassDevs  failed ! \n" ) ; 
exit ( 1 ) ; 


Devicelnterf aceData . cbSize  =  sizeof ( SP_DEVICE_INTERFACE_DATA) ; 

bResult  =  SetupDiEnumDevicelnterf aces (HardwareDevicelnfo, 

0, 

InterfaceGuid, 

0, 

SDevicelnterf aceData) ; 


if  (bResult  ==  FALSE)  { 

LPVOID  lpMsgBuf ; 

if  (FormatMessage (FORMAT_MESSAGE_ALLOCATE_BUFFER 
FORMAT_ME  S  S AGE_FROM_S  Y  STEM  | 
FORMAT_MESSAGE_IGNORE_INSERTS, 

NULL, 

GetLastError ( ) , 

MAKELANGID (LANG_NEUTRAL,  SUBLANG  DEFAULT), 
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(LPSTR)  SlpMsgBuf , 

0, 

NULL 

)  )  { 


printf ( "Error :  %s",  (LPSTR) lpMsgBuf ) ; 
LocalFree (lpMsgBuf )  ; 

} 

printf ( "SetupDiEnumDevice In ter faces  failed . \n" ) ; 
SetupDiDestroyDevicelnf oList (HardwareDevicelnfo)  ; 
exit ( 1 ) ; 

} 

SetupDiGet Device I nterf aceDetail ( 

HardwareDevicelnfo, 

& Devi cel nterf aceData, 

NULL, 

0, 

SRequiredLength, 

NULL 

)  ; 


Device Inter faceDetailData  =  (PSP_DEVICE_INTERFACE_DETAIL_DATA) 
LocalAlloc (LMEM  FIXED,  RequiredLength); 

if  (DevicelnterfaceDetailData  ==  NULL)  { 

SetupDiDestroyDevicelnf oList (HardwareDevicelnfo) ; 
printf ( "Failed  to  allocate  memory. \n"); 
exit ( 1 )  ; 


Device Inter f aceDetailData->cbSize  = 
sizeof (SP_DEVICE_INTERFACE_DETAIL_DATA) ; 

Length  =  RequiredLength; 

bResult  =  SetupDiGetDevicelnterf aceDetail  ( 
HardwareDevicelnfo, 

& Devi cel nterf aceData, 
DevicelnterfaceDetailData, 

Length, 

SRequiredLength, 

NULL) ; 

if  (bResult  ==  FALSE)  { 

LPVOID  lpMsgBuf; 

if  (FormatMessage (FORMAT_MESSAGE_ALLOCATE_BUFFER 
FORMAT_ME  S  S AGE_FROM_S  Y  STEM 
FORMAT_MESSAGE_IGNORE_INSERTS, 

NULL, 

GetLastError ( ) , 

MAKELANGID (LANG  NEUTRAL,  SUBLANG  DEFAULT), 
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(LPSTR)  SlpMsgBuf , 

0, 

NULL 

)  )  { 

MessageBox (NULL,  (LPCTSTR)  lpMsgBuf,  "Error",  MB_OK) ; 
LocalFree (lpMsgBuf ) ; 

} 

printf ( "Error  in  SetupDiGetDeviceInterfaceDetail\n" ) ; 

SetupDiDestroyDevicelnf oList (HardwareDevicelnfo)  ; 
LocalFree (DevicelnterfaceDetailData) ; 
exit ( 1 ) ; 

} 

return  Device Inter f aceDe tail Data- >Device Path; 

} 


BOOLEAN 

correctOsVersion ( ) 

{ 

OS VERS I ON INFO  osvi; 

ZeroMemory (&osvi,  sizeof (OSVERSIONINFO) ) ; 

osvi . dwOSVersionlnfoSize  =  sizeof (OSVERSIONINFO)  ; 

if ( ! GetVersionEx  ((OSVERSIONINFO  *)  &osvi)) 
return  FALSE; 

if  (  VER_PLATFORM_WIN32_NT==osvi . dwPlatf ormld  && 
osvi . dwMa j  orVersion  >  ACCEPTABLE_VERSION  ) 

{ 

if (osvi .dwMaj orVersion  ==  VISTA_VERSION_NUMBER  ) 
printf ( "Windows  VISTA  detected\n" )  ; 
else  if  (osvi .dwMaj orVersion  ==  XP_VERSION_NUMBER  ) 

printf ("Pre  VISTA  Version  of  Windows  detected\n" ) ; 

else 

printf ("Post  VISTA  Version (%d)  of  Windows  detected,  \ 
application  has  not  been  tested  for  this  version. \n", 
osvi . dwMaj orVersion) ; 

return  TRUE; 

} 

return  FALSE; 

} 

ULONGLONG 
CheckDiskSpace ( 

IN  HANDLE  hDumpFile 

) 

{ 

//  Check  that  there  is  sufficient  space  the  full  memory  dump 
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MEMORYSTATUSEX  ms; 

ms . dwLength  =  sizeof (MEMORYSTATUSEX) ; 

//Retrieves  information  about  the  system's  current  usage  of  both 
physical  and  virtual  memory. 

if (  ! GlobalMemoryStatusEx (  Sms  ))  { 

fprintf (  stderr,  "  ->  ERROR:  GlobalMemoryStatusEx  failed, 
%u\n",  GetLastError ()) ; 

return  ma.len; 

} 

LARGE  INTEGER  liDistanceToMove; 
liDistanceToMove . QuadPart  =  ms . ullTotalPhys ; 

//Sets  the  physical  file  size  for  the  specified  file  to  the 
current  position  of  the  file  pointer. 

ma.len  =  (ULONGLONG) ms . ullTotalPhys ; 

printf("File  Size  is : %f\n" , (float) ma . len/ ( 1024*1024 )) ; 
//uncomment  later 

//SetFilePointerEx (hDumpFile,  liDistanceToMove,  NULL, 

FILE_BEGIN) ; 

if  (! SetEndOfFile (hDumpFile) ) 

{ 

fprintf (  stderr,  "  ->  ERROR:  Not  enough  room  to  store 
memory  dump\n"); 

return  ma.len; 

} 

//Move  the  file  pointer  back  to  the  beginning  of  the  file. 
liDistanceToMove . QuadPart  =  0; 

SetFilePointerEx (hDumpFile,  liDistanceToMove,  NULL,  FILE  BEGIN); 
return  ma.len; 

} 

BOOLEAN 
WriteMemAddr ( 

IN  HANDLE  hDevice 


BOOLEAN  result  =  TRUE; 

ULONG  retLen  =  16  ; 

printf ( "Writing  Mem  Addr  to  driver. \n"); 

if (! WriteFile (hDevice,  Sma,  sizeof (memaddr) ,  SretLen,  NULL) ) { 
printf ( "ERROR:  Write  Mem  Addr  failed,  %u\n", 
GetLastError ( ) ) ; 

result  =  FALSE; 

}  else  { 

printf ("Mem  Addr  successfully  written  to  driver! \n"); 

} 


} 


return  result; 


BOOLEAN 
ReadRam ( 
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IN  HANDLE  hDevice, 

IN  HANDLE  hDumpFile, 
IN  ULONG  blockSize 


{ 

ULONGLONG 

ULONG 


bytesToRead 

offset 

blocks Writ ten 


=  blockSize, 

=  0; 


ma . offset; 


BOOLEAN 

bool 

PUCHAR 

BYTE 

int 


result  =  TRUE; 

loop  =  true; 

tempDataHolder  =  (PUCHAR) malloc (blockSize) ; 
zeros [TX_BLOCK_SIZE] =  {0}; 

iterations  =  0, 

goods  =  0, 

bads  =  0; 


/ /  while (  loop  ) 

while ( (offset ! =ma . len) ) 

{ 

if (  offset  +  bytesToRead  >=  ma.len) { 
bytesToRead  =  ma.len  -  offset; 
loop  =  false; 

} 

offset  +=  bytesToRead; 

printf("%d:  (  offset  %u  <", ++iterations, offset) ; 

printf("  ma.len  %u  )",  ma.len); 

printf("  ==  %d\n", (offset  !=  ma.len)); 

memset (tempDataHolder,  0,  blockSize); 

if  (  IReadFile  (hDevice,  //  file  to  read 

tempDataHolder,  //  buffer  to  receive  data 
blockSize,  //  number  of  bytes  to  read  in  total 
SblocksWritten,  //  number  of  bytes  read 
NULL) )  { 

bads++; 

printf  ("READRAM:  ReadFile  failed:  Error  %d\n", 

GetLastError ( ) ) ; 

//result  =  FALSE; 

//goto  Cleanup; 


}  else  { 

//printf ( "Bytes  returned  is  :%d!\n",  blocksWritten); 

//printf ( "ma . len  is  :%u!\n",  ma.len); 

goods++; 

} 

BOOL  writeSuccess  =  WriteFile (  hDumpFile, 

tempDataHolder, 

blockSize,  SblocksWritten,  NULL) ; 

//printf ( "Bytes  written  is  :%d!\n",  blocksWritten); 
if (  ! writeSuccess  )  { 

printf ("  ->  ERROR:  WriteFile  failed,  %u\n", 

GetLastError ( ) ) ; 

result  =  FALSE; 
goto  Cleanup; 


} 
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bads)  ; 


goods , 


} 


if (offset  >=  ma.len) ) 

printf ( "Completed  with  goods=%d,  bads=%d!\n", 
goto  Cleanup; 

} 


Cleanup : 

if (  hDumpFile  ) 

CloseHandle (  hDumpFile  ) ; 

return  result; 

} 
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memreader.inx 

[Version] 

Signature="$ WINDOWS  NT$ " 

Class=Sample 

ClassGuid={ 7 8A1C34 1-4539-1 Id3-B88D-00C04FAD5171 } 
Provider=%MSFT% 

DriverVer=03/20/2003, 5.00.3788 
CatalogFile=Kmdf Samples . cat 

[DestinationDirs ] 

Def aultDestDir  =  12 


Class  section 


[Classlnstall32] 

Addreg=SampleClassReg 

[  Sampled  as  sReg] 

HKR, , , 0, %ClassName% 

HKR, , Icon, , -5 

[SourceDisksNames ] 

1  =  %DiskIdl%, , , "" 

[SourceDisks Files ] 
memreader . sys  =  1,, 

•  'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k 

r 

;  MemReader  Install  Section 

•  'k'k'k'k'k'k-k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k-k'k'k'k'k'k'k'k-k'k'k'k'k'k'k'k'k'k'k 

r 

[Manufacturer] 

%StdMfg%=Standard, NT$ARCH$ 

;  Following  section  is  meant  for  Windows  2000  as  it 
;  cannot  parse  decorated  model  sections 
[Standard] 

r 

;  Hw  Id  is  root\MemReader 

r 

%MemReader . DeviceDesc%=MemReader  Device,  root\MemReader 

;  Decorated  model  section  take  precedence  over  undecorated 
;  ones  on  XP  and  later. 

[Standard . NT$ARCH$ ] 

%MemReader . DeviceDesc%=MemReader  Device,  root\MemReader 

[MemReader  Device. NT] 

CopyFiles=Drivers  Dir 

[Drivers  Dir] 
memreader . sys 
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; - Service  installation 

[MemReader  Device . NT . Services ] 

AddService  =  MemReader, %SPSVCINST  ASSOCSERVICE% ,  MemReader  Service  Inst 


;  -  MemReader  driver  install  sections 

[MemReader  Service  Inst] 


DisplayName 

ServiceType 

StartType 

ErrorControl 

ServiceBinary 

LoadOrderGroup 


=  %MemReader . SVCDESC° 
=  1 
=  3 
=  1 

=  %12%\memreader . sys 
=  Extended  Base 


SERVICE_KERNEL_DRIVER 
SERVICE_DEMAND_START 
SERVICE  ERROR  NORMAL 


; - MemReader  Device  Coinstaller  installation 


[DestinationDirs ] 

MemReader  Device_CoInstaller  CopyFiles  =  11 

[MemReader  Device . NT .Co Installers] 

AddReg=MemReader  Device  Colnstaller  AddReg 
CopyFiles=MemReader  Device_CoInstaller  CopyFiles 

[MemReader  Device  Colnstaller  AddReg] 

HKR, ,CoInstallers32, 0x00010000, 

"wdf coinstaller01005 . dll , Wdf Co I ns taller" 

[MemReader  Device_CoInstaller  CopyFiles] 
wdfcoinstaller01005 . dll 

[SourceDisks Files ] 

wdfcoinstaller01005 . dll=l  ;  make  sure  the  number  matches  with 
SourceDisksNames 

[MemReader  Device . NT . Wdf ] 

KmdfService  =  memreader,  memreader  wdfsect 
[MemReader  wdfsect] 

Kmdf LibraryVersion  =  1.5 


[Strings] 

SPSVCINST_ASSOCSERVICE=  0x00000002 
MSFT  =  "Microsoft" 

StdMfg  =  " (Standard  system  devices) " 

Diskldl  =  "Memory  Reader  Installation  Disk  #1" 
MemReader . DeviceDesc  =  "Memory  Reader  Service  Driver" 
MemReader . SVCDESC  =  "Memory  Reader  Service" 

ClassName  =  "Tools" 
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